Dag Sverre Seljebotn wrote: > 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. > Done!
Dag Sverre > >> 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.) > > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
