This part feels questionable to me. I don't think it's a good idea to add special cases to a protocol, so I think it's a good idea to include like in argument even if it wouldn't be useful.

I can also definitely imagine a library with multiple duck array types (e.g., pydata/sparse) that uses a single implementation that relies upon the like argument.

In that case, we could just have a separate __array_function__ on each of our types. But in any case, I would rather the like= kwarg was removed, it'd drive adaptability up quickly... But only for array creation functions, not others.

I can also definitely imagine a library with multiple duck array types (e.g., pydata/sparse) that uses a single implementation that relies upon the like argument.

But that would still rely on the NumPy dispatching system, no? In that case, I would expect the implementation to find out internally what is the actual type it needs to create and call NumPy's API to create a new object, much like what we do now with _meta in Dask.

In that case, we could just have a separate array_function on each of our types.

I'm not sure I understand your comment, but perhaps this is what I also tried to say in my comment just above?

But in any case, I would rather the like= kwarg was removed, it'd drive adaptability up quickly... But only for array creation functions, not others.

This is indeed my intent, I think the removal would be incredibly helpful for downstream libraries, even though I see why @shoyer is concerned about it. Perhaps would be nice to have more opinions here and see if they eventually converge in some direction.

I'm not sure I understand your comment, but perhaps this is what I also tried to say in my comment just above?

I mean that PyData/Sparse has different types for the different kinds of arrays it uses. Each of those types could have its own __array_function__ if we wanted to specialize array creation functions at all, instead of using one overarching __array_function__.

However I could think of da.Array using such a keyword to copy e.g. chunk sizes and inner array types from the source array.

I mean that PyData/Sparse has different types for the different kinds of arrays it uses. Each of those types could have its own array_function if we wanted to specialize array creation functions at all, instead of using one overarching array_function.

Oh, I see now. Yeah, that would be an alternative, but that could be a big burden too. So maybe in that case just not removing like= kwarg would make more sense?

However I could think of da.Array using such a keyword to copy e.g. chunk sizes and inner array types from the source array.

In the case of Dask, we can now use _meta to identify the inner array and use it as the like object. So there I think this wouldn't be a problem.

True, you would get the like= array in the form of self.

but that could be a big burden too

Not really, I consider it a separation of concerns.

Edit: I should clarify: If I wanted separate implementations, adding the protocol on each type of array isn't a big burden. If I wanted a unified one, I could just have one on the ABC, as I do now.

You're right, this makes sense. I was mostly saying this from the quick/seamless adaptability point-of-view.

I think we may want to go the C route (or get out the cython idea again). (The main issue in python is that there is no simple fast kwarg parsing solution available right now; python has the clinic internally, but that does not really help us).

The thing is that if this is in python, it will add at least one more function overhead call, which is fairly significant for a no-op. For many library functions it will not matter, but for the simple numpy functions it may.

I suspected people would lean this way, that's why I suggested this, from my perspective, I'm fine with either way. Maybe would be good to wait and see what others prefer too?

If we go the C path, IMO it doesn't make sense to extend the NEP quite significantly to point out all the adaptations needed to allow this. Unless people disagree with my point, I would only move the suggestion for Python implementation to a "rejected implementation proposal" section and mention that we are going the C way, but not describe all its details, as those details will likely not aggregate any important information to non-NumPy developers using that as a reference.

The only part that is currently not implemented in C is the public_api helper function from insidenumpy.core.overrides.array_function_dispatch:

        def public_api(*args, **kwargs):
            relevant_args = dispatcher(*args, **kwargs)
            return implement_array_function(
                implementation, public_api, relevant_args, args, kwargs)

Maybe we could save the overhead of parsing args and kwargs in public_api if we wrote it in C? Honestly I'm not entirely sure.

This uses a closure over implementation and public_api, which is probably the main reason why it wasn't written in C in the first place.

Sorry for being unresponsive. I have been thinking about this, what I suppose could work is to add the like kwarg to the C implementation of each function, and then do the inverse process:

1. If like is valid, call the C implementation of override;
2. The C implementation of override would have a callback to the Python implementation which would dispatch to the downstream library.

Admittedly, I don't know much about C Python and the current C implementation of the __array_function__ override, so I don't know whether this is something that is possible to achieve. Besides this, I also don't see any other alternatives to doing it the Python way, as per my proposal in the NEP itself. Thoughts on this @shoyer ?