Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mix & match behavior of array objects from different libraries #399

Closed
leofang opened this issue Feb 28, 2022 · 3 comments
Closed

Mix & match behavior of array objects from different libraries #399

leofang opened this issue Feb 28, 2022 · 3 comments
Labels
Question General question.

Comments

@leofang
Copy link
Contributor

leofang commented Feb 28, 2022

This question was raised by @shwina during an internal discussion: If I create two array objects, one from cupy.array_api and another from numpy.array_api, if I do a+b or b+a what would happen? I think we should obviously return TypeError following Python's convention, so the question is which page should we document this expectation?

@rgommers
Copy link
Member

In https://data-apis.org/array-api/latest/purpose_and_scope.html#out-of-scope it says:

Non-goals for the API standard include:
...
Making it possible to mix multiple array libraries in function calls.
Most array libraries do not know about other libraries, and the functions they implement may try to convert “foreign” input, or raise an exception. This behaviour is hard to specify; ensuring only a single array type is used is best left to the end user.

We have tended to not specify exception types and other such things that are out of scope, undefined behavior, etc. TypeError seems clearly the correct exception type, but I'm not sure it's a good idea to document this under the Python operators section or elsewhere. Unless we can think of a good way to have a self-contained section where we document the most common exceptions and when to use them somehow.

@rgommers rgommers added the Question General question. label Feb 28, 2022
@asmeurer
Copy link
Member

asmeurer commented Mar 1, 2022

We don't really require type checks of any kind anywhere. We have type hints, but no requirement that those be translated to checks at runtime. My reading of the spec is that such a thing is garbage in, garbage out. It might produce an error or it might work, and if it does work, it might be on accident. Requiring a + b to raise a TypeError when b is not an array object of the same library as a (or a Python scalar) means a.__add__ has to have a if not isinstance(other, array): raise TypeError check at the top. And the same for every other method and function. Even the strict NumPy implementation does not do this (in fact, numpy.array_api.Array operator methods return NotImplemented, meaning another library could interface with them if it wanted to).

@rgommers
Copy link
Member

rgommers commented Mar 9, 2023

I believe the question is answered and we already have text that addresses the point, quoted in italics above. So I'll close this issue.

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Question General question.
Projects
None yet
Development

No branches or pull requests

3 participants