<html><body><br><br><blockquote class="hm_quoted_text" style="padding-left:8px;margin:0;border-left:1px solid rgb(185,185,185);color:rgb(100,100,100)">
<div>On 6. Jun 2018 at 05:41, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>> wrote:</div><p>
<br></p><div dir="ltr"><div>Oh wait, since the decorated version of the ufunc will be the one in the public numpy API it won't break. It would only break if the callable that was passed in *wasn't* the decorated version, so it kinda *has* to pass in the decorated function to preserve backward compatibility. Apologies for the noise.<br></div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 5, 2018 at 7:39 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hmm, does this mean the callable that gets passed into __array_ufunc__ will change? I'm pretty sure that will break the dispatch mechanism I'm using in my __array_ufunc__ implementation, which directly checks whether the callable is in one of several tuples of functions that have different behavior.</div></blockquote></div></div></div></blockquote><div><br></div><div>Section “Non-Goals” states that Ufuncs will not be part of this protocol, __array_ufunc__ will be used to override those as usual.<br><br><div class="">Sent from <a href="https://www.helloastro.com">Astro</a> for Mac</div></div><blockquote class="hm_quoted_text" style="padding-left:8px;margin:0;border-left:1px solid rgb(185,185,185);color:rgb(100,100,100)"><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div></blockquote></div></div></div>
</blockquote>
</body></html>