[Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Matti Picus matti.picus at gmail.com
Tue Jun 5 17:43:10 EDT 2018

On 05/06/18 14:11, Stephan Hoyer wrote:
> On Tue, Jun 5, 2018 at 12:35 PM Marten van Kerkwijk 
> <m.h.vankerkwijk at gmail.com <mailto:m.h.vankerkwijk at gmail.com>> wrote:
>     Things would, I think, make much more sense if
>     `ndarray.__array_ufunc__` (or `*_function__`) actually *were* the
>     implementation for array-only. But while that is something I'd
>     like to eventually get to, it seems out of scope for the current
>     discussion.
> If this is a desirable end-state, we should at least consider it now 
> while we are designing the __array_function__ interface.
> With the current proposal, I think this would be nearly impossible. 
> The challenge is that ndarray.__array_function__ would somehow need to 
> call the non-overloaded version of the provided function provided that 
> no other arguments overload __array_function__. However, currently 
> don't expose this information in any way.
> Some ways this could be done (including some of your prior suggestions):
> - Add a coerce=True argument to all NumPy functions, which could be 
> used by non-overloaded implementations.
> - A separate namespace for non-overloaded functions (e.g., 
> numpy.array_only).
> - Adding another argument to the __array_function__ interface to 
> explicitly provide the non-overloaded implementation (e.g., func_impl).
> I don't like any of these options and I'm not sure I agree with your 
> goal, but the NEP should make clear that we are precluding this 
> possibility.

What is the difference between the `func` provided as the first argument 
to `__array_function__` and `__array_ufunc__` and the "non-overloaded 
version of the provided function"?

This NEP calls it an "arbitrary callable".
In `__array_ufunc__` it turns out people count on it being exactly the 


More information about the NumPy-Discussion mailing list