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

[Stephan Hoyer]

On Thu, Sep 13, 2018 at 10:30 AM Stephan Hoyer <shoyer at gmail.com> wrote:

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180919/60ad0f4d/attachment.html>