> 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 - we do type inference and replace bytes with char * - we run into trouble because == already has a different semantics for char * objects. I think the change that we should make is in the second step there, not the third -- I think we're throwing away valuable type information by replacing "Python bytes object" with "char *", so that's the place to fix it. I think we should just introduce a new type which represents a bytes object that we're modeling with a char *, which we can call whatever -- maybe "InferredCharStar". It can simply be a wrapper around a char * -- in fact, it can just *be* char * in the generated C/C++ code -- but it maintains Python semantics in any Python statement. We don't even need to expose it to the programmer if we don't want, since it only really exists at compile-time, though I'd probably be in favor of exposing it. (I'm a long-time Scheme and Python programmer that loves types ... I wonder if I should seek help for that. :P) 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. -cc _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
