<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 3, 2018 at 2:00 PM, Hameer Abbasi <span dir="ltr"><<a href="mailto:einstein.edison@gmail.com" target="_blank">einstein.edison@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><span class=""><blockquote class="m_5881109939389664326hm_quoted_text" style="padding-left:8px;margin:0;border-left:1px solid rgb(185,185,185);color:rgb(100,100,100)"><div>The rules for dispatch with ``__array_function__`` match those for</div><div dir="ltr"><div>``__array_ufunc__`` (see</div><div>`NEP-13 <<a href="http://www.numpy.org/neps/nep-0013-ufunc-overrides.html" target="_blank">http://www.numpy.org/neps/<wbr>nep-0013-ufunc-overrides.html</a>><wbr>`_).</div><div>In particular:</div><div><br></div><div>-  NumPy will gather implementations of ``__array_function__`` from all</div><div>   specified inputs and call them in order: subclasses before</div><div>   superclasses, and otherwise left to right. Note that in some edge cases,</div><div>   this differs slightly from the</div><div>   `current behavior <<a href="https://bugs.python.org/issue30140" target="_blank">https://bugs.python.org/<wbr>issue30140</a>>`_ of Python.</div><div>-  Implementations of ``__array_function__`` indicate that they can</div><div>   handle the operation by returning any value other than</div><div>   ``NotImplemented``.</div><div>-  If all ``__array_function__`` methods return ``NotImplemented``,</div><div>   NumPy will raise ``TypeError``.</div></div></blockquote><div><br></div></span><div>I’d like to propose two changes to this:</div><div><ul style="font-stretch:normal;line-height:17px;background-color:rgba(0,0,0,0)"><li style="color:rgb(0,0,0);font-family:"Helvetica Neue";font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;text-decoration:none">``np.<wbr>NotImplementedButCoercible`` be a part of the standard from the start.</li><ul style="color:rgb(0,0,0);font-family:"Helvetica Neue";font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;text-decoration:none"><li>If all implementations return this, only then should it be coerced.</li><ul><li>In the future, it might be good to mark something as coercible to coerce it to ``ndarray`` before passing to another object’s ``__array_ufunc__``.</li></ul><li>This is necessary if libraries want to keep old behaviour for some functions, while overriding others.</li><li>Otherwise they have to implement overloads for all functions. This seems rather like an all-or-nothing choice, which I’d like to avoid.</li><li>It isn’t too hard to implement in practice.</li></ul></ul></div></div></blockquote><div>I think the issue is real but I would be slightly worried about adding multiple possible things to return - there is a benefit to an answer being either "I cannot do this" or "here's the result". I also am not sure there is an actual problem: In the scheme as proposed, implementations could just coerce themselves to array and call the routine again. (Or, in the scheme I proposed, call the routine again but with `coerce=True`.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><ul style="font-stretch:normal;line-height:17px;background-color:rgba(0,0,0,0)"><li>Objects that don’t implement ``__array_function__`` should be treated as having returned ``np.<wbr>NotImplementedButCoercible``.</li><ul><li>This has the effect of coercing ``list``, etc.</li><li>At a minimum, to maintain compatibility, if all objects don’t implement ``__array_function__<wbr>``, the old behaviour should stay.</li></ul></ul></div></div></blockquote><div>I think that in the proposed scheme this is effectively what happens.<br><br></div><div>-- Marten<br></div></div></div></div>