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

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._arrayufunc_ (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 arrayfunction interface. With the current proposal, I think this would be nearly impossible. The challenge is that ndarray.arrayfunction would somehow need to call the non-overloaded version of the provided function provided that no other arguments overload arrayfunction. 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.arrayonly). - Adding another argument to the arrayfunction interface to explicitly provide the non-overloaded implementation (e.g., funcimpl). 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 np.ufunc.

Matti

More information about the NumPy-Discussion mailing list