<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Sep 13, 2018 at 10:30 AM Stephan Hoyer <<a href="mailto:shoyer@gmail.com">shoyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br></div></div><div dir="ltr"><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 class="gmail_quote"><div dir="ltr">On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level array functions":<div><a href="http://www.numpy.org/neps/nep-0018-array-function-protocol.html" target="_blank">http://www.numpy.org/neps/nep-0018-array-function-protocol.html</a><br><div><br></div><div><div>Since the last round of discussion, we added a new section on "Callable objects generated at runtime" clarifying that to handle such objects is out of scope for the initial proposal in the NEP.</div><br>If there are no substantive objections within 7 days from this email, then the NEP will be accepted; see NEP 0 for more details.<br><br></div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I've merged the PR. What next?</div><div><br></div><div>Chuck </div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I rolled back Chuck's merge of the "Acceptance" PR for this NEP because (1) it was not clear that if had reached consensus and (2) I still wanted to make a few changes based on this discussion.</div><div><br></div><div>I have now drafted these revisions to the NEP to clarify its stance around backwards compatibility, and the type of the "types" argument: <a href="https://github.com/numpy/numpy/pull/11943" target="_blank">https://github.com/numpy/numpy/pull/11943</a></div><div> </div><div>I have *not* included any form of the explicit "end-user opt-in" requested by Nathaniel. I don't think it is warranted based on the scope of anticipated future changes; see my earlier post [1] for details. Nobody has seriously suggested that we would release this functionality and later eliminate the ability to override NumPy functions entirely in the future.</div><div><br></div><div>Of course, requiring an onerous explicit opt-in would be fine while this feature is initially under development, and until we are sure that checks for overriding arbitrary NumPy functions are fast enough to be generally viable. In particular, we should verify that __array_function__ does not meaningfully impact performance for major downstream components of the SciPy stack. But I think running standard benchmark suites (e.g., with ASV) and user testing of release candidates would be enough.</div><div><br></div><div>If you have still have major objections to this version of proposal, please raise them unambiguously -- preferably with an formal veto [2].</div></div></div></blockquote><div><br></div><div>Again, if anyone (yes, I'm looking at you, Nathaniel!) still has objections please speak up soon.</div><div><br></div><div>If I don't hear anything, I'm going submit a PR to mark this proposal as "Accepted" tomorrow (one week after these latest revisions).</div><div><br></div><div>As Chuck noted, "Tentatively accepted" or "Experimental" would probably be a better status, but that currently isn't one of our options for NEPs. In any case, I would love to move on from debate to implementation!</div><div><br></div><div>As a side note, I recently noticed a CuPy pull request (<a href="https://github.com/cupy/cupy/pull/1650/files">https://github.com/cupy/cupy/pull/1650</a>) to add __array_function__. It's a testament to our proposed interface that the full PR is 9 lines of code without tests.</div></div></div>