allow using __array_function__ as a fallback for missing Array API functions

[keewis]

As discussed in #8834 (comment), this swaps the order of special casing for types implementing both __array_function__ and __array_namespace__, such that the Array API is preferred over __array_function__.

I've also disabled passing the out kwarg to nanprod, as that was the only occurrence where we actually do that, all other nan* functions silently ignore that kwarg.

• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst

cc @tomwhite

[TomNicholas]

This seems good, but does it cover this comment? #8834 (comment)

[tomwhite]

Thanks @keewis - this would be very helpful!

[keewis]

does it cover this comment? #8834 (comment)

I don't think it does, but I think array types that implement both __array_{ufunc,function}__ and __array_namespace__ would prefer to use __array_namespace__, so I believe we don't change anything for that (not that I know of any array type that actually fully implements both besides numpy).

[dcherian]

This almost certainly breaks vectorized indexing with cupy if you don't implement the fallback vindex using explicit_indexing_adapter.

Though how are the pint tests passing? Do we have indexing tests with pint?

[keewis]

This almost certainly breaks vectorized indexing with cupy

As far as I can tell, cupy does not implement __array_namespace__ (unless you used cupy.array_api or array_api_compat.cupy to create the array, where the former apparently is sunset in cupy=14), so it will still use the NdArrayLikeIndexingAdapter. Same with pint, it doesn't implement __array_namespace__.

That said, we should definitely try to provide an implementation for vindex, I just don't think it is as urgent.

[dcherian]

OK yes, lot less urgent then. I thought they had all implemented __array_namespace__ for their main api like numpy.

[keewis]

cupy plans to do so in v14 (see cupy/cupy#8470), they try to be a drop-in replacement for numpy – though obviously there is some lag.

[dcherian]

I'm confused now, why does the indexing adapter affect what's used for reductions?

[keewis]

I don't think that's the case. What I mentioned in the meeting was that we could use __array_function__ as a fallback for nan* reductions, whereas choosing the wrong indexing adapter will cause xarray to try indexing with a method the array type might not support.

I guess this is kinda hard to figure out implicitly, and I'd love to have a way (a special attribute like __xarray_preferred_array_protocol__?) to explicitly communicate which protocol is preferred. That way, we won't have to worry about cupy and pint implementing the Array API, and cubed can just set that attribute to state that it considers __array_function__ a fallback and instead prefers to use __array_namespace__ indexing.

[dcherian]

array_function as a fallback for nan* reductions,

👍 sorry I got confused.