<div dir="ltr"><div dir="ltr">On Fri, Apr 26, 2019 at 1:24 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">Thanks, this helped clarify what's going on here. This example is clear. The problem seems to be that there's two separate discussions in this thread:<br></div><div class="gmail_quote"><div>1. your original proposal, __numpy_implementation__. it does not have the problem of your np.concatenate example, as the "numpy implementation" is exactly the same as it is today. <br></div><div>2. splitting up the current numpy implementation into *multiple* entry points. this can be with and without coercion, with and without checking for invalid values etc.</div><div><br></div><div>So far NEP 18 does (1). Your proposed __numpy_implementation__ addition to NEP 18 is still (1). Claiming that this affects the situation with respect to backwards compatibility is incorrect.</div><div><br></div><div>(2) is actually a much more invasive change, and one that does much more to increase the size of the NumPy API surface. And yes, affects our backwards compatibility situation as well.<br></div><div><br></div><div>Also note that these have very different purposes: <br></div><div>(1) was to (quoting from the NEP) "allow
using NumPy as a high level API for efficient multi-dimensional array
operations, even with array implementations that differ greatly from
<code class="gmail-m_-8060410567240713418gmail-docutils gmail-m_-8060410567240713418gmail-literal gmail-m_-8060410567240713418gmail-notranslate"><span class="gmail-m_-8060410567240713418gmail-pre">numpy.ndarray</span></code>."</div><div>(2) is for making duck arrays work with numpy implementations of functions (not just with the NumPy API)</div><div><br></div><div>I think (1) is mostly achieved, and I'm +1 on your NEP addition for that. (2) is quickly becoming a mess, and I agree with Nathaniel's sentiment above "I shouldn't expect __array_function__ to be useful for duck arrays?". For (2) we really need to go back and have a well thought out design. Hameer's mention of uarray could be that. Growing more __array_*__ protocols in a band-aid fashion seems unlikely to get us there.</div></div></div></blockquote><div><br></div><div>Yes, very well put. I agree, let's try to keep focused on (1) for now.</div><div><br></div><div>(2) got brought up because of potential confusing about what "__numpy_implementation__" means, but certainly we don't want to figure out those issues now.</div><div><br></div><div>To that end, I'd love to hear more suggestions for naming what I tentatively called "__numpy_implementation__". I suppose we could always go for "__implementation_used_by_numpy_ndarray_array_function__" ;)</div></div></div>