<div dir="ltr"><div dir="ltr">On Sat, Apr 27, 2019 at 11:44 AM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi All,</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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 <code class="gmail-m_-6355769718347941757gmail-docutils gmail-m_-6355769718347941757gmail-literal gmail-m_-6355769718347941757gmail-notranslate"><span class="gmail-m_-6355769718347941757gmail-pre">__array_function__</span></code> methods, which should be rare."</div></div></div></div></blockquote><div><br></div><div>I also have a hard time seeing how we could ever make such major backwards incompatible changes to NumPy.</div><div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>¬†<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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,<br></div></div></blockquote><div><br></div><div>Sticking with __wrapped__ is fine with me too. It's a reasonable name.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>