<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 28, 2019 at 5:41 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 Ralf,</div><div><br></div><div>Thanks for the comments and summary slides. I think you're over-interpreting my wish to break people's code! I certainly believe - and think we all agree - that we remain as committed as ever to ensure that</div><div>```</div><div>np.function(inputs)</div><div>```</div><div>continues to work just as before. My main comment is that I want to ensure that no similar guarantee will exist for<br></div><div>```</div><div>np.function.__wrapped__(inputs)</div><div>```</div><div>(or whatever we call it). I think that is quite consistent with NEP-18, since as originally written there was not even the possibility to access the implementation directly (which was after long discussions about whether to allow it, including ideas like `import numpy.internal_apt as np`). In this respect, the current proposal is a large deviation 
from the original intent, so we need to be clear about what we are promising.</div><div><br></div><div>In summary, I think the guarantees should be as follows:</div><div>1.If you call np.function and<br></div><div>  - do not define __array_function__, changes happen only via the usual cycle.</div><div>  - define __array_function__, you take responsibility for returning the result.</div><div>2. If you call np.function.__wrapped__ and<br></div><div>  - input only ndarray, changes happen only via the usual cycle;</div><div>  - input anything but ndarray, changes can happen in any release.<br></div></div></blockquote><div><br></div><div>Thanks. These guarantees make sense I think. __wrapped__ is new, so specifying that it should be called only with ndarrays seems reasonable.<br></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></div><div>On the larger picture,in your slides, the further split that happens is that if no override is present, the first thing that actually gets called is not the function implementation but rather `ndarray.__array_function__`. I think it is important to add this to your mental image (and the slides), </div></div></blockquote><div><br></div><div>This is tricky. Yes, that's how it's implemented, but making __array_function__ do anything at all is potentially hazardous. Conceptually I think it's meant to be a do-nothing wrapper that just forwards directly to the actual wrapped function. Although if we could get it consistent, it may work.<br></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>since it means that generic parts of the implementations (like coercion ;-), can be moved there. </div></div></blockquote><div><br></div><div>If all wrapped functions have identical generic parts, because there's just one ndarray.__array_function__. Are you sure that all functions have identical generic parts? I'm not - it's a bit of work, but I'd be surprised if there is even one line of code that's common between all functions. And if you have to special case functions within ndarray.__array_function__ to let some have asarray and some asanyarray etc., there's probably also a significant amount of overhead added.<br></div><div> </div><div>There's also the thought of exposing the dispatching mechanism itself in the NEP: <a href="https://www.numpy.org/neps/nep-0018-array-function-protocol.html#use-outside-of-numpy">https://www.numpy.org/neps/nep-0018-array-function-protocol.html#use-outside-of-numpy</a>. That may also get more complicated.</div><div><br></div><div>By the way, can you think of any other generic part besides coercion? There's other things that could be nice to skip (input validation for one) but nothing is generic. <br></div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></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>For ufuncs, this is relatively easy, for other functions less so since they differ quite a bit in what coercion they do.</div><div><br></div><div>All the best,</div><div><br></div><div>Marten<br></div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div></div>