On Thu, Sep 13, 2018 at 10:30 AM Stephan Hoyer <sho...@gmail.com> wrote:
> On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.har...@gmail.com> > wrote: > >> On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <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]. > Again, if anyone (yes, I'm looking at you, Nathaniel!) still has objections please speak up soon. 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). 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! As a side note, I recently noticed a CuPy pull request ( https://github.com/cupy/cupy/pull/1650 <https://github.com/cupy/cupy/pull/1650/files>) to add __array_function__. It's a testament to our proposed interface that the full PR is 9 lines of code without tests.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
