Questions related to adoption

[rgommers]

Here's a list of questions that we need to think about when driving adoption in both array/tensor libraries, and further downstream.

1. Do we want array libraries to adopt this into a public or private namespace. I.e., only accessible via arrayobject.__array_namespace__() or additionally via a direct import? If the latter, what should it be named? related to How to expose API to downstream libraries? #16
2. What is the design pattern to work around np.asarray in downstream libraries?
3. Now that we have some features that are kind of optional (e.g., boolean indexing), can we define and should we recommend a testing strategy to figure out how portable some piece of code really is? Also relevant if libraries add extra things into the standard module because it's too hard to remove (e.g., methods on array object).
4. Should we have a central place to track adoption and compliance level?
5. Can downstream libraries sanely use type annotations when supporting multiple array libraries? (related to the Protocol mentioned in the Static typing section)

Please add more questions if you can think of them.

[rgommers]

3. Now that we have some features that are kind of optional (e.g., boolean indexing), can we define and should we recommend a testing strategy to figure out how portable some piece of code really is? Also relevant if libraries add extra things into the standard module because it's too hard to remove (e.g., methods on array object).

Two options were suggested here:

• Have a standalone reference implementation, which exposes only the API in the standard. It could use an array class which is backed by numpy.ndarray, but wraps it and forwards all the calls. Performance isn't important here after all.
• Use Mypy, ensure that the annotations for the the array_api namespace only include the APIs in the standard.

[shoyer]

• What is the design pattern to work around np.asarray in downstream libraries?

I opened #122 for this one before I saw this issue :)

[shoyer]

6. How should libraries check array types, e.g., what is the equivalent of np.ndarray for use in isinstance or type annotations? Perhaps we should include the equivalent of an Array base class as part of the spec. __array_namespace__() provides the same information, but it's less convenient to use.

[rgommers]

How should libraries check array types, e.g., what is the equivalent of np.ndarray for use in isinstance or type annotations? Perhaps we should include the equivalent of an Array base class as part of the spec. __array_namespace__() provides the same information, but it's less convenient to use.

Some thoughts on this:

• adding a base class in the spec isn't useful, it would need to be in a (small, standalone) package as an ABC. it's not impossible we'll end up with something like that, but just for enabling isinstance is probably not enough reason to do it.
• isinstance isn't too useful in general I'd say. the first thing some function using arrays will do is use __array_namespace on its inputs already.
• a typing.Protocol can be done in the spec, and would be useful to include I think.

[rgommers]

1. Do we want array libraries to adopt this into a public or private namespace. I.e., only accessible via arrayobject.__array_namespace__() or additionally via a direct import? If the latter, what should it be named? related to gh-16

Tentative answer: yes, make it available as a direct import, and name it array_api.

[leofang]

How to specify device for the very first array? -> #156

[kgryte]

How to specify device for the very first array?

This should now be supported via the inspection API where you can query the list of supported devices.

[kgryte]

Have a standalone reference implementation, which exposes only the API in the standard. It could use an array class which is backed by numpy.ndarray, but wraps it and forwards all the calls.

This should now be satisfied via https://github.com/data-apis/array-api-strict.