Skip to content

DOC: confusing documentation for Python level np.intp and C-level npy_intp #26092

@ogrisel

Description

@ogrisel

Issue with current documentation:

In #24888 the npy_intp type was updated to alias Py_ssize_t (instead of intptr_t as previously). Its documentation was updated accordingly:

.. c:type:: npy_intp
``Py_ssize_t`` (a signed integer with the same size as the C ``size_t``).
This is the correct integer for lengths or indexing. In practice this is
normally the size of a pointer, but this is not guaranteed.
.. note::
Before NumPy 2.0, this was the same as ``Py_intptr_t``.
While a better match, this did not match actual usage in practice.
On the Python side, we still support ``np.dtype('p')`` to fetch a dtype
compatible with storing pointers, while ``n`` is the correct character
for the ``ssize_t``.

However, in the same file, the NPY_INTP enumerated type still refers to the equivalence with intptr_t (size of void*):

.. c:enumerator:: NPY_INTP
The enumeration value for a signed integer type which is the same
size as a (void \*) pointer. This is the type used by all
arrays of indices.

followed by:

Integer that can hold a pointer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The constants **NPY_INTP** and **NPY_UINTP** refer to an
enumerated integer type that is large enough to hold a pointer on the
platform. Index arrays should always be converted to **NPY_INTP**
, because the dimension of the array is of type npy_intp.

Furthermore, the documentation for the Python-level dtype with matching name np.intp also refers to equivalence with intptr_t:

.. attribute:: intp
Alias for the signed integer type (one of `numpy.byte`, `numpy.short`,
`numpy.intc`, `numpy.int_`, `numpy.long` and `numpy.longlong`)
that is the same size as a pointer.
Compatible with the C ``intptr_t``.
:Character code: ``'p'``

Idea or request for content:

So I am confused:

  • are the documentation sections paragraph for the enumeration value and Python-level dtype object up to date?
  • if so, I think it would be important to add a note to make the type discrepancy explicit (while explaining that this should not be a problem to confused Py_ssize_t with intptr_t on most platforms).
  • if this not intended (that is, if the Python dtype and the enumeration value are now all aligned on Py_ssize_t/npy_intp), then those paragraphs should be updated.

Note: the documentation of npy_uintp np.uintp would deserve a similar clarification.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions