ENH: Allow ndarray.__array_function__ to dispatch functions that use like= - #27504

@seberg - It took me some wondering but I ended up thinking there is no need for wrapping, at least not inside ndarray.__array_function__. The reason is that for subclasses that do not define __array_function__, we never get here: for like=some_non_override_subclass(), array_implement_c_array_function_creation just returns NotImplemented:

FWIW, in the regular case of dispatching on some array-like argument, dispatcher_vectorcall does the same: it just calls the default implementation if all arguments have the default __array_function__:

p.s. For subclasses that do define __array_function__, we get here if they call super().__array_function__ (which Quantity does to avoid having to know about _implementation). But for Quantity at least, wrapping would not be helpful because __array_wrap__ does not have the right context (e.g., the unit of the scalar one might want to use for np.full); I think it would be similar if, e.g., we were to write an MaskedArray.__array_function__, where the output mask might depend on the actual function and parameters.

Ah, good point. So right now it actually doesn't matter to begin with, although we may want to change that at some point, I suppose. At some point we might not reject the like= part, but maybe the other point is that basically evryone should implement __array_function__ anyway.
(And rather we should clarify that calling _implementation or func() is a way to do that without overriding all functions.)

Arg, so here is the thing that I guess still makes me pause:

class SomeClass(np.ndarray):
    pass

# This returns a plain array:
np.ones(3, like=np.arange(3).view(SomeClass))
# This returns a subclass (of course):
np.empty_like(np.arange(3).view(SomeClass))

So to me, it seems like it would be a fix to do what you said: Pass on self and call __array_wrap__ additionally here (or whatever it is that we call for empty_like).
Unless that would be problematic for your case?!

Basically, there is the weird thing that for other functions we often (but not always!) preserve subclasses, but for creation functions like= just doesn't, when that seems odd.

OTOH, I am not 100% sure either that it is doing much of a favor to preserve the subclasses here if those subclasses don't bother implementing __array_function__ maybe they are not important enough to get a chance/say... (should play well enough with the returned NumPy array)?

TL;DR: I still feel it seems more right to return subclasses, but I am also fine with putting this in, it doesn't break anything (although it might slightly cement the behavior).

@seberg - it remains a tricky one. On the one hand, I think that the whole __array_ufunc__/__array_function__ system was always meant to replace the __array_wrap__ stuff, so I'd rather not rely on __array_wrap__. On the other hand, returning a subclass by default seems somewhat logical.

But maybe more importantly is that it is tricky, since if we do it for the like= NEP35 cases, then why not for the other functions? But those often do it themselves already. So, it is not clear to me how to implement it correctly.

Thinking concretely for the case of astropy, it would not help the implementations to have a subclass returned, as we will regardless do things like set units, etc., after this call happens. Also, assuming this really should be done generally, not all functions should return subclasses (e.g., for quantities, isclose should still return a regular plain ndarray of bool). Really, in our case the main use of super().__array_function__ is just that it means we can pass on our subclasses to the implementation without having to know where those reside. This saves us from writing wrappers for a large number of functions...

So, overall perhaps best to just take this as a bug fix that allows using the like= functions, in a way that is exactly the same as the NEP 20 ones.

Sorry, one further thought: in principle, I think it would be OK for the actual C code that creates arrays to know how to create a subclass, and then __array_function__ could pass on the type of class. But it seems weird to have code in __array_function__ to have to care about what implementations do - it should just pass things on, not do any wrapping itself.

Yeah, it isn't clear cut. Because I can also say that most subclasses that do not implement __array_function__ (or are lazy about it), should interact gracefully with NumPy arrays.

And if they interact gracefully, then it actually makes sense to just return a plain array!

So maybe, I should just stop worry about it, either way someone who tries to be lazy by not implementing these (falling back), will have to do more than they hope.

And while I may have a slight tendency to the other being the better default... In the end, it is just a default!

So... Let's give this a shot, I don't think anyone else will chime in after all.