Hi all,
Here is what is probably the second-to-last NEP for NumPy 2.0 (the last one
being the informational summary NEP of all major changes):
https://github.com/numpy/numpy/pull/25542. Full text below.
A lot of the work has been under discussion since the 2.0 developer meeting
in April and has been merged. A few of PRs that didn't make sense as
standalone changes without this NEP are still open (see the "NumPy 2.0 API
Changes" label), and there's a couple ones that still need to be opened.
For editorial comments on the text, please comment on GitHub. For
significant conceptual/design comments, please post them on this thread.
Cheers,
Ralf
=
NEP 56 — Array API standard support in NumPy's main namespace
=
:Author: Ralf Gommers
:Author: Mateusz Sokół
:Author: Nathan Goldbaum
:Status: Draft
:Type: Standards Track
:Created: 2023-12-19
:Resolution: TODO mailing list link
Abstract
This NEP proposes adding full support for the 2022.12 version of the array
API
standard in NumPy's main namespace for the 2.0 release.
Motivation and scope
.. note::
The main changes proposed in this NEP were presented in the NumPy 2.0
Developer Meeting in April 2023 (see `here
<
https://github.com/numpy/archive/blob/main/2.0_developer_meeting/NumPy_2.0_devmeeting_array_API_adoption.pdf
>`__
for presentations from that meeting) and given a thumbs up there. The
majority of the implementation work for NumPy 2.0 has already been
merged.
For the rest, PRs are ready - those are mainly the items that are
specific
to array API support and we'd probably not consider for inclusion in
NumPy
without that context. This NEP will focus on those APIs and PRs in a bit
more detail.
:ref:`NEP47` contains the motivation for adding array API support to NumPy.
This NEP expands on and supersedes NEP 47. The main reason NEP 47 aimed for
a
separate ``numpy.array_api`` submodule rather than the main namespace is
that
casting rules differed too much. With value-based casting being removed
(:ref:`NEP50`), that will be resolved in NumPy 2.0. Having NumPy be a
superset
of the array API standard will be a significant improvement for code
portability to other libraries (CuPy, JAX, PyTorch, etc.) and thereby
address
one of the top user requests from the 2020 NumPy user survey [4]_ (GPU
support).
See `the numpy.array_api API docs (1.26.x) <
https://numpy.org/doc/1.26/reference/array_api.html#table-of-differences-between-numpy-array-api-and-numpy
>`__
for an overview of differences between it and the main namespace (note that
the
"strictness" ones are not applicable).
Experiences with ``numpy.array_api``, which is still marked as experimental,
have shown that the separate strict implementation and separate array object
are mostly good for testing purposes, but not for regular usage in
downstream
libraries. Having support in the main namespace resolves this issue. Hence
this
NEP supersedes NEP 47. The ``numpy.array_api`` module will be moved to a
standalone package, to facilitate easier updates not tied to a NumPy release
cycle.
Some of the key design rules from the array API standard (e.g., output
dtypes
predictable from input dtypes, no polymorphic APIs with varying number of
returns controlled by keywords) will also be applied to NumPy functions that
are not part of the array API standard, because those design rules are now
understood to be good practice in general. Those two design rules in
particular
make it easier for Numba and other JIT compilers to support NumPy or
NumPy-compatible APIs. We'll note that making existing arguments
positional-only and keyword-only is a good idea for functions added to
NumPy in
the future, but will not be done for existing functions since each such
change
is a backwards compatibility break and it's not necessary for writing code
that
is portable across libraries supporting the standard. An additional reason
to
apply those design rules to all functions in the main namespace now is that
it
then becomes much easier to deal with potential standardization of new
functions already present in NumPy - those could otherwise be blocked or
forced
to use alternative function names due to the need for backwards
compatibility.
It is important that new functions added to the main namespace integrate
well
with the rest of NumPy. So they should for example follow broadcasting and
other rules as expected, and work with all NumPy's dtypes rather than only
the
ones in the standard. The same goes for backwards-incompatible changes
(e.g.,
linear algebra functions need to all support batching in the same way, and
consider the last two axes as matrices). As a result, NumPy should become
more
rather than less consistent.
We'll note that one remaining incompatibility will be that NumPy is
returning
array scalars rather than 0-D arrays in most cases where
