Repository navigation
Questions related to adoption #120
Description
Activity
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_apinamespace only include the APIs in the standard.
- Have a standalone reference implementation, which exposes only the API in the standard. It could use an array class which is backed by
- How should libraries check array types, e.g., what is the equivalent of
np.ndarrayfor use inisinstanceor type annotations? Perhaps we should include the equivalent of anArraybase class as part of the spec.__array_namespace__()provides the same information, but it's less convenient to use.
- How should libraries check array types, e.g., what is the equivalent of
How should libraries check array types, e.g., what is the equivalent of
np.ndarrayfor use inisinstanceor type annotations? Perhaps we should include the equivalent of anArraybase 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
isinstanceis probably not enough reason to do it. isinstanceisn't too useful in general I'd say. the first thing some function using arrays will do is use__array_namespaceon its inputs already.- a
typing.Protocolcan be done in the spec, and would be useful to include I think.
- 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
- 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.- Do we want array libraries to adopt this into a public or private namespace. I.e., only accessible via
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.
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.
- changed the title
[-]tracking issue - questions related to adoption[/-][+]Questions related to adoption[/+]on Apr 4, 2024 - locked and limited conversation to collaborators
on Apr 4, 2024
Here's a list of questions that we need to think about when driving adoption in both array/tensor libraries, and further downstream.
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? #16np.asarrayin downstream libraries?Protocolmentioned in the Static typing section)Please add more questions if you can think of them.