> On Thursday, Sep 13, 2018 at 7:30 PM, Stephan Hoyer <sho...@gmail.com > (mailto:sho...@gmail.com)> wrote: > > > On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.har...@gmail.com > (mailto:charlesr.har...@gmail.com)> wrote: > > > > > > On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <sho...@gmail.com > > (mailto:sho...@gmail.com)> wrote: > > > > > > > > > > > > > I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level > > > array functions": > > > > > > > > > > > > > > > http://www.numpy.org/neps/nep-0018-array-function-protocol.html > > > > > > > > > > > > > > > > > > > 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. > > > > > > If there are no substantive objections within 7 days from this email, > > > then the NEP will be accepted; see NEP 0 for more details. > > > > > > > I've merged the PR. What next? > > > > Chuck > > 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. > > I have now drafted these revisions to the NEP to clarify its stance around > backwards compatibility, and the type of the "types" argument: > https://github.com/numpy/numpy/pull/11943 > > > > > 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. > > > > > 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. > > If you have still have major objections to this version of proposal, please > raise them unambiguously -- preferably with an formal veto [2]. > > Best, > Stephan > > > > > [1] https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html > [2] https://docs.scipy.org/doc/numpy/dev/governance/governance.html > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
+1 from me. The edits are readable and clean, and a good compromise. Best Regards, Hameer Abbasi
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
