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

[Stephan Hoyer]

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].

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