Robert Bradshaw, 25.04.2010 06:57: > On Apr 22, 2010, at 12:52 AM, Dag Sverre Seljebotn wrote: >> Lisandro Dalcin wrote: >>> I've not closed the ticket, because I would like to know your >>> opinions. For your convenience, you have below my comments. >>> >>> Pushed: http://hg.cython.org/cython-devel/rev/1a9bfb4ff18a >>> Tested: Linux32/64 and Windows32 (MSVC and MinGW) >>> >>> Comments: 'ssize_t' is not a C99 standard type. If available, core >>> Python(>2.4) defines Py_ssize_t to ssize_t. If ssize_t is not >>> available, then any Cython code using ssize_t will fail at C compile >>> time. I do not think we should #define or typedef ssize_t if it is >>> missing, but raise your voice if you do not agree. For Py>=2.5, >>> detecting a missing ssize_t is trivial (macro available pyconfig.h) >>> and then we could conditionally "#define ssize_t Py_ssize_t" (or >>> ptrdiff_t). >> >> My vote is in favor of simply always making "ssize_t" in Cython always >> mean Py_ssize_t in C. >> >> This is because I want some Py_ssize_t without the special index >> behaviour, so that I can start recommend using it in numerical loops. >> Py_ssize_t is the "correct" type to use for indexing NumPy arrays, but >> has problems when using it in mathematical expressions because of the >> special index coercion behaviour. > > This sounds very reasonable to me.
+1. If CPython defines one as the other anyway, it won't make a difference in Py2.5+, and older Python versions a) have 64 bit issues anyway and b) are already out of maintenance and thus will die out rather sooner than later. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
