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

Stephan Hoyer shoyer at gmail.com
Tue Jun 5 14:49:00 EDT 2018


On Mon, Jun 4, 2018 at 7:35 AM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi Stephan,
>
> Another potential consideration in favor of NotImplementedButCoercible is
>> for subclassing: we could use it to write the default implementations of
>> ndarray.__array_ufunc__ and ndarray.__array_function__, e.g.,
>>
>> class ndarray:
>>     def __array_ufunc__(self, *args, **kwargs):
>>         return NotIImplementedButCoercible
>>     def __array_function__(self, *args, **kwargs):
>>         return NotIImplementedButCoercible
>>
>> I think (not 100% sure yet) this would result in exactly equivalent
>> behavior to what ndarray.__array_ufunc__ currently does:
>>
>> http://www.numpy.org/neps/nep-0013-ufunc-overrides.html#subclass-hierarchies
>>
>
> As written would not work for ndarray subclasses, because the subclass
> will generically change itself before calling super. At least for Quantity,
> say if I add two quantities, the quantities will both be converted to
> arrays (with one scaled so that the units match) and then the super call is
> done with those modified arrays. This expects that the super call will
> actually return a result (which it now can because all inputs are arrays).
>

Thanks for clarifying. This is definitely trickier than I had thought.

If Quantity.__array_ufunc__ implemented overrides by calling the public
ufunc method again (instead of calling super), then it would still work
fine with this change. But of course, in that case you would not need
ndarray.__array_ufunc__ defined at all.

I will say that personally, I find the complexity of the current
ndarray.__array_ufunc__ implementation a little inelegant, and I would
welcome simplifying it. But I also try to avoid implementation inheritance
entirely [2], for exactly the same reasons why refactoring
ndarray.__array_ufunc__ here would be difficult (inheritance is fragile).
So I would be happy to defer to your judgment, as someone who actually uses
subclassing.

https://hackernoon.com/inheritance-based-on-internal-structure-is-evil-7474cc8e64dc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180605/1b486635/attachment.html>


More information about the NumPy-Discussion mailing list