On 05/06/18 14:11, Stephan Hoyer wrote:
On Tue, Jun 5, 2018 at 12:35 PM Marten van Kerkwijk <m.h.vankerkw...@gmail.com <mailto:m.h.vankerkw...@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 `np.ufunc`.

Matti
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Reply via email to