[Numpy-discussion] numpy, Py_ssize_t, cython and 64 bits python 2.4
Sun Nov 9 21:38:30 CST 2008
On Mon, Nov 10, 2008 at 8:29 AM, Dag Sverre Seljebotn
> Robert is right, it could just as well say "ctypedef int npy_intp".
> Perhaps it should (but it would not fix the problem). I didn't think too
> much about it, just copied the definition I found in the particular
> NumPy headers on my drive, knowing it wouldn't make a difference.
> Some comments on the real problem:
> What the Cython numpy.pxd file does is implementing PEP 3118 , which
> is supported by Cython in all Python versions (ie backported, not
> following any standard). And, in Py_buffer, the strides and shapes are
> Py_ssize_t* (which is also backported as David mentions). So, in order
> to cast the shape and stride arrays and return them in the Py_buffer
> struct, they need to have the datatype defined by the backported PEP
> 3118, i.e. the backported Py_ssize_t, i.e. int.
Thanks for those explanation.
> a) Rather than raise an exception on line 56, one can instead create new
> arrays (using malloc) and copy the contents of shape and strides to
> arrays with elements of the right size.
> b) These must then be freed in __releasebuffer__ (under the same
> c) Also "info.obj" must then be set to "self". Note that it is set to
> None on line 91, that line should then be moved.
Ok, sounds easy enough.
> OTOH, one could also opt for changing how PEP 3118 is backported and say
> that "for Python 2.4 we say that Py_buffer has Py_intptr_t* fields
> instead". This would be more work to get exactly right, and would be
> more contrived as well, but is doable if one really wants to get rid of
> the extra mallocs.
This sounds like the right solution, but OTOH, since I am not familiar
with the cython codebase at all, I will prepare a patch following the
first solution, and I guess you can always improve it later.
More information about the Numpy-discussion