<div dir="ltr"><div>On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br></div><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>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">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><br></div><div>Best,</div><div>Stephan</div><div><br></div><div>[1] <a href="https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html">https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html</a></div><div>[2] <a href="https://docs.scipy.org/doc/numpy/dev/governance/governance.html">https://docs.scipy.org/doc/numpy/dev/governance/governance.html</a></div></div></div>