Hoyt Koepke wrote: >>> I kinda like the idea of having two types that are only really >>> different in corner cases like these, e.g. cint , clong, (maybe int, >>> long), and that these are an explicit request for c semantics in every >>> way. Other types like int (maybe py_int?) are a request for python >>> sematics, even if it means a slight speed penalty over c semantics. >>> Making this distinction explicit would seem to make everyone happy -- >>> both the python coders who want speed and the c coders who work in >>> python -- though it would probably mean more work for the cython >>> developers. It also seems like more of a long-term solution, as there >>> are other cases this would resolve (like overflows in c but not >>> python). >> Ooh, I definitely like this idea. > > Thanks. > > It seems like the only places where this matters are with integers. > Thus if cython had one type, say py_integer (to distinguish it from > PyIntObject*, like you mentioned), which in the C code would be a long > or long long, but the semantics in the generated code would always be > determined by python syntax.
But you can't emulate the Python int semantics without also adding arbitrary size values. So, where would you draw the line? And how would you explain to users why this type has part X of Python's int semantics but not part Y, and why this type exists at all? I'm afraid of the complexity that this duplication of type names adds to the language. Plus, it does not solve the problem at hand, which is a problem with the semantics of an operator and not with the semantics of a type. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
