>> 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.

> (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.)

Maybe, though I see this as a fall-back default for people who don't
want to work through making sure the C types works.  Thus defaulting
to py_integer whenever there's a question would make sense.

The only gotchas here are with integer division (upcast to double) and
overflow, and these issues may make this option more difficult (unless
you go with the matlab way of making everything a double and
downcasting to integers as appropriate.)

As for floats, just alias py_float with double.

With this in place, cdef int, long, etc. could be as in c, and I'd
have a way to teach people to cythonize their python code without
worrying about weird corner cases.

-- Hoyt

++++++++++++++++++++++++++++++++++++++++++++++++
+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ [email protected]
++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to