Stéfan van der Walt wrote: > Hi all, > > The numpy.pxd included with Cython currently defines npy_intp, so that > we can use it as > > cimport numpy as np > np.npy_intp > > However, all the other types are defined as np.type_t, e.g., np.int_t. > Would you mind adding np.intp_t and np.uintp_t (while keeping > np.npy_intp for backwards compatibility)?
Hmm. Yes. Basically the idea is that a) npy_X corresponds directly to the C API b) X_t corresponds to the runtime dtype t So, there's intp_t and uintp_t lacking for b). Can't push right now so keep nagging me if I don't. > As a side note, it may be safer to use the definitions of npy_intp and > npy_uintp from the numpy header, rather than Py_ssize_t and Py_size_t. > In some earlier versions of Python (e.g., 2.4), these were not the > same. Yep, ctypedef npy_intp intp_t and so on. > > Then, I also have a quick question: why is a person allowed to do > > cdef extern from something: > ctypedef int Py_ssize_t > > when Py_ssize_t is not an int? Is this a Cython-specific idea? Cython makes few assumptions about the size of external typedef types. Basically "Py_ssize_t" is carried through to C verbatim.... So the idea is that Cython should not rely on the size of external typedefs to be properly specified. This is what makes int32_t and friends work at all. However this is a somewhat inconsistent idea which is not followed everywhere in Cython, and every attempt to resolve it properly has been aborted. So that kind of code will fail e.g. on integer division :-( So this is something that must still be resolved but "mostly works OK" :-( (BTW Py_ssize_t is now a builtin type in Cython, but I'm discussing the idea in general.) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
