<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 4:31 PM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com">m.h.vankerkwijk@gmail.com</a>> wrote:<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>Hi All,<br></div><div><br></div><div>Reading the discussion again, I've gotten somewhat unsure that it is helpful to formalize a way to call an implementation that we can and hopefully will change. Why not just leave it at __wrapped__? I think the name is no worse and it is more obvious that one relies on something private.<br></div></div></blockquote><div><br></div><div>I'm not convinced about the name either. NEP 18 also suggests adopting the protocol in other libraries, so for SciPy would we have to name it __scipy_implementation__? Not sure that's better or worse than a generic __wrapped__</div><div><br></div><div>I don't see why the numpy implementation must be considered private though. It's public today, and there's little wrong with keeping it public. The "it can change" doesn't really apply, it has the same backwards compat guarantees going forward that we have now.</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></div><div><br></div><div>I ask in part since I could see a good case for having a special method that is available only for functions that do no explicit casting to array, i.e., that are ready to accept array mimics (and for which we're willing to guarantee that would not change). For instance, functions like np.sinc that really have no business using more than ufuncs under the hood, i.e., which any class that has __array_ufunc__ can call safely. Or (eventually) all those functions that just end up calling `concatenate` - those again could easily be made safe for a class that just overrides `np.concatenate` using __array_function__. In essence, this would be any function that does not do `<a href="http://np.as" target="_blank">np.as</a>(any)array` but just relies on array attributes.<br></div><div><br></div><div>But the above obviously presumes a vision of where this is headed, which I'm not sure is shared...</div></div></blockquote><div><br></div><div>This is an orthogonal topic I think - you want multiple implementations, "safe" and "unsafe" (or fast vs checking for invalids vs robust for subclasses, etc. - lots of options here).</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div><div><br></div></div></div>