Please don't hesitate to edit this issue

The board has some other issues as well, but I would like to list (and add) an issue to track the main C-API Changes we are anticipating/preparing for 2.0.

We can and should do these changes now. There may be downstream CI fallout, but SciPy started to adapt so we can try to start enforcing NumPy 2.0 compilation.

Listing mostly changes here that I think are relatively important to do.

"Smaller" changes

• Removal of many rarely used/unused functions (including many that were already deprecated)
• Modifying the default integer on 64-bit windows: make the default intp: API: Make 64bit default integer on 64bit windows #24224
  • The PR was in a good shape, but other Python changes created a lot of merge conflicts :(.
  • IMO, we just need to do this and see what breaks, unless someone can spend a lot of time.
• Modify intp to be ssize_t (Py_ssize_t as ssize_t is nonstandard). This is irrelevant on most platforms, but better matches how we use it. It might mean niche platforms like OpenVMS will require additional fixes (although they are probably broken in many subtle ways and this will fix that).
  • It might be good to allow np.dtype("n") and np.dtype("p"), but we can do so via Python aliases in principle. (I.e. make sure p and P map to intptr_t or size_t equivalence even on niche platforms.)
  • Ensure that NumPy 2.0 requires NPY_TARGET_VERSION >= NPY_2_0_API_VERSION when those types should differ (otherwise ABI is broken).
• Bump NPY_MAXARGS and NPY_MAXDIMS. To do this, we have to do one or both of:
  • Add compat inline functions to access all of the iterator versions (or a new struct/version of the iterators for NumPy internal things)
  • Live with the fact that some functions will not support high dimensional arrays.
  • I had a start on this but it got stalled a bit last time because @mattip didn't much like the idea of not removing the limit completely. I agree to target removing the limit completely (i.e. remove NPY_MAXDIMS as a public constant), but I would prefer to be pragmatic and live with the fact that we will limit to 64dims/args in some ufuncs parts for now and 32dims in some iterator paths. (Basically, consider especially the 32dim limits as a minor bug, but due to iterator use hard to fix.)
• @mattip would like to not have any API returning borrowed references. I am not sure how much we have, but I agree.
  • If API is not very niche, I would lean towards simply adding a non-borrowing version of the API.
• Consider moving auxdata in the strided-loop signature into context struct:
  • We should aim to make the new DType/UFunc API public. The main thing that makes me pause is the ufunc strided/inner loop signature. I am considering moving auxdata to be part of the struct passed in (since we commonly don't use auxdata).
• Expose PyArray_Pack. Maybe deprecate PyArray_SETITEM? Part of experimental API exposure, not going to backport as Nathan didn't think it worthwhile enough.
• Vet the new DType/UFunc API for const users. E.g. resolve_descriptors should pass the original descriptors with PyArray_Descr *const *, since you are not allowed to mutate it.

Larger Changes

• Make the PyArray_Descr struct opaque.
  • C code will have to use new, version specific, static-inline functions to fetch some struct members.
  • Cython 3 code should not mind this change.
• Hiding structs further structs.