On Mon, Mar 16, 2009 at 9:03 AM, Hoyt Koepke <[email protected]> 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. (Although it certainly has its own set of complications, like deciding which semantics and return type "wins" if you divide a C-variant machine int by a Python-variant machine int.) It feels much nicer to me than any of the other "have it both ways" suggestions (compiler flags, compiler pragmas, multiple operator names, built-in functions). One minor note: I don't like the name py_int, because my first thought on seeing "cdef py_int i" would be that i holds a PyIntObject* (the C type that corresponds to the Python-language int type). Carl _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
