[Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

Hameer Abbasi einstein.edison at gmail.com
Thu Sep 13 14:50:28 EDT 2018


> On Thursday, Sep 13, 2018 at 7:30 PM, Stephan Hoyer <shoyer at gmail.com (mailto:shoyer at gmail.com)> wrote:
>
>
> On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.harris at gmail.com (mailto:charlesr.harris at gmail.com)> wrote:
>
>
>
>
> > On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com (mailto:shoyer at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/b16900e6/attachment-0001.html>


More information about the NumPy-Discussion mailing list