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