This should be merged as nep-0018 once the initial comments are handled. Deeper discussion, as I understand the process, should take place on the mailing list

I cannot find this mentioned on the mailing list, so then here:

1. I'm rather unclear about the use oftypes. It can help me decide what to do, but I would still have to find the argument in question. If we pass anything at all, should it just be the argument itself that does not get immediately recognized byndarray? Or, better still, perhaps a tuple of all arguments that were inspected?
2. For subclasses, it would be very handy to havendarray.__array_function__, so one can call super after changing arguments. (For__array_ufunc__, there was lots of question about whether this was useful, but it really is!!).
3. Thisndarray.__array_function__ might also help solve the problem of cases where coercion is fine: it could have an extra keyword argument (saycoerce) that would call the function with coercion in place.
4. Indeed, thendarray.__array_function__ could just be used inside the "dance" function, and then the actual implementation of a given function would just be a separate, private one.

The authors should send it out to the mailing list.

Still needed for merge (as perNep Workflow, the merge should be sooner rather than later):

• rebase against master to remove the failing test
• rename the file todoc/neps/nep-0018-array-function-protocol.rst

Another general comment, since this is still not on the mailing list, yet I'm thinking about it now: Since speed fornormal operation should be impacted as minimally as possible, there should be obvious ways to ensure no type checking dance is done. Some possible solutions (which I think should be in the NEP, even if as discounted options):

• Two namespaces, one for the undecorated base functions, and one for the decorated ones. The idea would be that if one knows one is dealing with arrays only, one would doimport numpy.array_only as np. The latter namespace would be the one automatically used forndarray.__array_function__.
• Decorator automatic insertion of aarray_only=np._NoValue (orcoerce and perhapssubok=... if not present) in the function signature, so that users who know that they have arrays only could passarray_only=True (name to be decided). This would be most useful if there were also some type of configuration parameter that could set the default ofarray_only.

rebase against master to remove the failing test
rename the file to doc/neps/nep-0018-array-function-protocol.rst

Done! My apologies for the delays on this@mattip .

Thanks@mrocklin

I've now posted the NEP to the mailing list for discussion
https://mail.python.org/pipermail/numpy-discussion/2018-June/078127.html

@mhvk with regards tondarray.__array_function__ in particular, I don't have strong feelings here and am happy to differ to your judgment (you know I don't like subclassing). Certainly there is virtue in using the same approach as__array_ufunc__. I'll add a brief note on this in the next revision.

With regards to namespaces, please note the section on "Separate namespace" that is already in the NEP text.

Are we ready to start the approval process for NEP 18?

@mattip almost -- I'd like to add short paragraphs on class methods and dtypes to "Alternatives" to make it clear that we aren't aren't ruling out such options in the future.

Hello, I am aCuPy developer.
This feature is important for NumPy compatible library.
I create a PR for CuPy in experimentalcupy/cupy#1650 . Please use it if you want.
Thanks.