[Numpy-discussion] size_t or npy_intp?

Francesc Alted faltet@pytables....
Tue Jul 27 10:24:48 CDT 2010


A Tuesday 27 July 2010 17:17:55 Dag Sverre Seljebotn escrigué:
> Kurt Smith wrote:
> > Looking at the bufferinfo struct for the buffer protocol, it uses
> > `Py_ssize_t`:
> >
> > struct bufferinfo {
> >      void *buf;
> >      Py_ssize_t len;
> >      int readonly;
> >      const char *format;
> >      int ndim;
> >      Py_ssize_t *shape;
> >      Py_ssize_t *strides;
> >      Py_ssize_t *suboffsets;
> >      Py_ssize_t itemsize;
> >      void *internal;
> > } Py_buffer;
> >
> > So everyone is using signed values where it would make more sense (to
> > me at least) to use unsigned.  Any reason for this?

My reason was just being consistent with `malloc(size_t size)` signature (and 
that the C world seems to widely use `size_t` for sizes).

> >
> > I'm using `npy_intp` since Cython does it that way :-)
> 
> And Cython (and NumPy, I expect) does it that way because Python does it
> that way. And that really can't be changed.
> 
> The reasons are mostly historical/for convenience. And once 64-bit is
> more widespread, do we really care about the one bit?
> 
>  From PEP 353:
> 
> 
>     Why not size_t56 <http://www.python.org/dev/peps/pep-0353/#id9>
> 
> An initial attempt to implement this feature tried to use size_t. It
> quickly turned out that this cannot work: Python uses negative indices
> in many places (to indicate counting from the end). Even in places where
> size_t would be usable, too many reformulations of code where necessary,
> e.g. in loops like:
> 
> for(index = length-1; index >= 0; index--)
> 
> This loop will never terminate if index is changed from int to size_t.

Ok, I'm not going to break Python/NumPy conventions so you convinced me: I'll 
use `npy_intp` then.

Thanks!

-- 
Francesc Alted


More information about the NumPy-Discussion mailing list