Craig Citro, 10.10.2010 09:07: >> I think it's ok to consider this specific case a bug. If a user wants >> pointer comparison, "is" is the most explicit operator w.r.t. Python >> semantics. Using strcmp() for the "==" operator on char* values makes sense >> to me. We special case char* all over the place, so this is just another >> exception. > > Personally, I'm +1 on considering this a bug, but I'm a big -1 > (basically -as_many_as_my_vote_is_worth) on changing the behavior of > comparison operators on some/all pointer types to fix it. As I > understand, the chain of events causing the problem is this: > > - user writes code with == on Python (bytes) objects, expecting > Python semantics
Not quite. In the specific example at hand, it's a byte string literal and a char* variable. There is no syntactic difference between a char* literal and a bytes literal in Cython, so the fact that Cython currently assumes char* types for both sides is totally valid and legitimate. > - we do type inference and replace bytes with char * No type inference involved in the example, just plain char* values on both sides. Quite the contrary, the current behaviour is that byte string literals are in fact char* literals and may eventually get coerced into Python bytes objects at compile time or runtime when used in a Python context. So we never replace bytes by char*, only char* by bytes. > [...]Then there's also no need to introduce any more special > cases on char * behavior, or by extension any other C types. This > closely mirrors the situation with trying to use a C int for a Python > int without changing the semantics, and probably runs into some of the > other weird and thorny issues. Note that types only have very little intrinsic behaviour in Cython. Most of their visible behaviour just results from the way the syntax nodes treat them. So it's not like a new type would reduce the need for special cases. That being said, I bet there are also cases where it would come as a surprise that a char* value has Python semantics in some contexts but not in others, depending on whether Cython is able to infer a bytes/char* duality or not. It's worth taking a deeper look, but I'd want to avoid complicating the semantics by introducing a special type for special cases that Cython can figure out, thus making it less predictable how the type will behave in a certain situation. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
