On Sat, Apr 27, 2019 at 11:44 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk < > m.h.vankerkw...@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.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
