[Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API
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
> 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.,
> - 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
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