To clarify for others what (in my opinion) the state is:

1. The current numpy.array_api seems mainly useful and needed for testing. However, if the main use is testing, it does not need to live in NumPy (at least not NumPy proper).
   • This namespace should probably be moved elsewhere.
2. Libraries (who are the main audience) probably want a pragmatic implementation for use with NumPy arrays. That could be np.array_api, or it could be only available through np.ndarray.__array_namespace__().
   • This namespace needs to be created or consolidated as otherwise libraries may each end up creating their own mock version. Fortunately, it should be fairly straight forward to do so.

With respect to CuPy, the second namespace is interesting. Whatever we do for NumPy (or CuPy) should translate almost 1:1 to the other, but I suspect a change like replacing numpy with cupy can probably not be avoided?

I think we can indeed discuss moving the current numpy.array_api to a standalone package, especially if it helps avoid duplication. Flip sides of that coin:

• The code will have to have explicit differences in places to deal with numpy vs cupy
• It will have to declare a dependency on a specific version of numpy (and cupy), or at least it won't work with older numpy versions, because there's a number of fixes that went into numpy to support standard compliant behaviour
• There's now extra overhead in testing, releasing, etc.

@leofang where do you think it should live? And do you think the overhead will go down in total, given that there's now a separate package to maintain? Also, if that exists standalone, will you still vendor it into CuPy or declare a dependency on it?

2. Libraries (who are the main audience) probably want a pragmatic implementation for use with NumPy arrays.

This is related to gh-21135 and to data-apis/array-api#400. There's a lot more detail there, so I suggest to keep this issue about the current, strictly compliant-only version of numpy.array_api and discuss this point on those other issues.

I think we can indeed discuss moving the current numpy.array_api to a standalone package, especially if it helps avoid duplication. Flip sides of that coin:

• The code will have to have explicit differences in places to deal with numpy vs cupy

I do not think that is necessary. CuPy should not need such an implementation since the purpose of this package will be to test that a library does not require API beyond the minimal array-API implementation (should generalize to all implementors).
To test if they work with CuPy, they should test explicitly against the new CuPy array-API implementation.

• It will have to declare a dependency on a specific version of numpy (and cupy), or at least it won't work with older numpy versions, because there's a number of fixes that went into numpy to support standard compliant behaviour
• There's now extra overhead in testing, releasing, etc.

Right, these are indeed annoying. OTOH, you will not be locked into the NumPy release cycle. Since this package is most interesting for testing/CI, maybe that is the bigger advantage? I.e. it is OK if tests are not run always. Tests might use a switches like: TEST_ARRAY_APIS=available or TEST_ARRAY_APIS="minimal,numpy.ndarray,cupy.ndarray so that CI will enforce running, but users won't have to worry about having the right NumPy version.

To test if they work with CuPy, they should test explicitly against the new CuPy array-API implementation.

I think that the reason @leofang brought this up is to keep the CuPy and NumPy version of the current, largely duplicated, code in sync. If the answer is now: "let numpy.array_api and cupy.array_api grow beyond strict compliance to be more useful", that doesn't really answer that concern. The code remains in NumPy and in CuPy and remains duplicated (you just called it new here, but it's not really new - it's a superset of what we have right now, most of it remains the same).

it has moved!