Skip to content

Questions related to adoption #120

Closed
Closed
Questions related to adoption#120
Labels
Tracking IssueTracking issue.

Description

@rgommers
rgommers
opened on Jan 27, 2021

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.

Activity

  1. rgommers commented on Jan 29, 2021

    @rgommers
    rgommers
    on Jan 29, 2021
    MemberAuthor

    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.

  2. shoyer commented on Jan 30, 2021

    @shoyer
    shoyer
    on Jan 30, 2021
    Contributor
    • What is the design pattern to work around np.asarray in downstream libraries?

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

  3. shoyer commented on Jan 30, 2021

    @shoyer
    shoyer
    on Jan 30, 2021
    Contributor
    1. 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.

  4. rgommers commented on Feb 16, 2021

    @rgommers
    rgommers
    on Feb 16, 2021
    MemberAuthor

    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.

  5. rgommers commented on Feb 16, 2021

    @rgommers
    rgommers
    on Feb 16, 2021
    MemberAuthor
    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.

  6. leofang commented on Apr 3, 2021

    @leofang
    leofang
    on Apr 3, 2021
    Contributor

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

  7. kgryte
    added
    Tracking IssueTracking issue.
    on Oct 4, 2021

  8. kgryte commented on Apr 4, 2024

    @kgryte
    kgryte
    on Apr 4, 2024
    Contributor

    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.

  9. kgryte commented on Apr 4, 2024

    @kgryte
    kgryte
    on Apr 4, 2024
    Contributor

    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.

  10. kgryte
    changed the title [-]tracking issue - questions related to adoption[/-] [+]Questions related to adoption[/+] on Apr 4, 2024
  11. data-apis
    locked and limited conversation to collaborators on Apr 4, 2024
  12. kgryte
    converted this issue into a discussion #772 on Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Tracking IssueTracking issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions