On Sat, Apr 27, 2019 at 11:44 AM Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk <m.h.vankerkwijk@gmail.com> wrote:
Hi All,

I agree with Ralf that there are two discussions going on, but also with Hameer that they are related, in that part of the very purpose of __array_function__ was to gain freedom to experiment with implementations.

This may have been your motivation, but I don't see that in NEP 18 anywhere. On the contrary - the single sentence under "backwards compatibility" in the NEP reads: "This proposal does not change existing semantics, except for those arguments that currently have __array_function__ methods, which should be rare."

I also have a hard time seeing how we could ever make such major backwards incompatible changes to NumPy.

I do think it's useful to consider possible future changes to duck-typing support in NumPy, to the extend that they interact with the current design of NEP-18. It seems quite plausible to me that we might want to expose some version of "NumPy's implementation" of its functions. This adds to the possible confusion of a name like "numpy implementation", regardless of whether or not we will break backwards compatibility.

Whatever we call it, the proposed attribute is just a way to say "skip dispatch with __array_function__" when calling a NumPy function. This is an API that we are already committed to maintaining, so like the rest of NEP-18 I don't think the functionality itself has any implications for backwards compatibility.
In the end, the proposed goal for __numpy_implementation__ really seems simple: to provide a better name for __wrapped__. But to me the discussion has proven that this is in fact not a good idea. It does suggest stability where there should be none, and the name itself is contentious. Maybe it is best to just stick with __wrapped__? If so, the the only change would be that we mention it in the NEP,

Sticking with __wrapped__ is fine with me too. It's a reasonable name.

I don't care exactly what name we pick, but as I said before I think "__wrapped__" is a bad name for this functionality, because it is neither self-descriptive nor searchable.

For example: what does "np.something.__wrapped__" mean? It tells you that this is a "wrapped" function, but it doesn't say *what* is wrapped. The name has all the same issues as a generic name like "__implementation__". The way that NumPy uses functools.wraps() internally is an implementation detail, not something that users should need to know.

Worst, "__wrapped__" would be difficult to search for, because it already means something in Python (referring to functools.wrapped). At least "__numpy_implementation__" and "__skipping_array_function__" are both unique tokens without any existing meaning.