<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 6, 2019 at 12:53 AM Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.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">On Mon, Sep 2, 2019 at 11:21 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>
> On Mon, Sep 2, 2019 at 2:09 PM Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br><br>
On Tue, Sep 3, 2019 at 2:04 AM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com" target="_blank">einstein.edison@gmail.com</a>> wrote:<br>
> The fact that we're having to design more and more protocols for a lot<br>
> of very similar things is, to me, an indicator that we do have holistic<br>
> problems that ought to be solved by a single protocol.<br>
<br>
But the reason we've had trouble designing these protocols is that<br>
they're each different :-). If it was just a matter of copying<br>
__array_ufunc__ we'd have been done in a few minutes...<br></blockquote><div><br></div><div>I don't think that argument is correct. That we now have two very similar protocols is simply a matter of history and limited developer time. NEP 18 discusses in several places that __array_ufunc__ should be brought in line with __array_ufunc__, and that we can migrate a function from one protocol to the other. There's no technical reason other than backwards compat and dev time why we couldn't use __array_function__ for ufuncs also.</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div></div></div>