BUG: reject ndarrays in binary operators

[ev-br]

A minimal fix for gh-102.
As a byproduct, add several check_device calls, where previously missing.

[asmeurer]

Should add some tests for this.

[ev-br]

I believe 6d67d46#diff-8047174d1f9158b619da8e809ed90fd46404caae67e7f687c5ba3a77f5bddc40R215 is a faithful representation of what we can test.

[asmeurer]

Ah sorry, I didn't notice that last bit was actually already in the tests. That should be fine.

This change seems OK. It fixes some of the more egregious uses of __array__. Maybe we should also check scipy with this change too (should we add something like that to the CI?), since the last time things broke so spectacularly.

[ev-br]

Indeed, scipy's $ python dev.py test -b array_api_strict passes locally with this PR.

W.r.t. CI testing of downstreams, yeah, this might be useful. An immediate downside though is that it'll make a CI run from under five minutes to > 1/2 hour. It is definitely worth thinking a bit about a larger CI strategy, here or in -compat. Maybe as a cron job or a manual trigger. I feel it should be a separate PR though.

[asmeurer]

I would go with whatever's the most pragmatically useful for testing scipy. It would be a good idea to test it before doing releases at the very least, to avoid the issues we had previously.

[asmeurer]

Maybe we should explicitly only reject ndarray. That way NotImplemented can still work on other types (although I honestly don't know how important that is).

[ev-br]

I'd think that mixing different array objects is a bad idea in general, and is basically impossible to make consistent. Even when it fails, there are just too many possible reasons or failure modes.
So one either buys in duck-typing all the way (and whatever quacking falls out, it does), or say no to anything which is not the same array namespace. If -strict strives to be strict, the latter makes sense, it seems.
That said, I'm happy with whatever you think is best.

In [4]: xp.arange(5) + cp.arange(5)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[4], line 1
----> 1 xp.arange(5) + cp.arange(5)

File cupy/_core/core.pyx:1265, in cupy._core.core._ndarray_base.__add__()

File cupy/_core/_kernel.pyx:1286, in cupy._core._kernel.ufunc.__call__()

File cupy/_core/_kernel.pyx:159, in cupy._core._kernel._preprocess_args()

File cupy/_core/_kernel.pyx:145, in cupy._core._kernel._preprocess_arg()

TypeError: Unsupported type <class 'array_api_strict._array_object.Array'>

In [5]: cp.arange(3) + xp.arange(3)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[5], line 1
----> 1 cp.arange(3) + xp.arange(3)

File cupy/_core/core.pyx:1269, in cupy._core.core._ndarray_base.__add__()

TypeError: operand type(s) all returned NotImplemented from __array_ufunc__(<ufunc 'add'>, '__call__', array([0, 1, 2]), Array([0, 1, 2], dtype=array_api_strict.int64)): 'ndarray', 'Array'