[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

[Stephan Hoyer]

On Sat, Apr 27, 2019 at 11:44 AM Ralf Gommers <ralf.gommers at gmail.com>
wrote:

> On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk <
> m.h.vankerkwijk at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190427/02f95394/attachment-0001.html>