[Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

[Ralf Gommers]

On Thu, Jun 13, 2019 at 7:07 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

>
>
> On Thu, Jun 13, 2019 at 12:46 PM Stephan Hoyer <shoyer at gmail.com> wrote:
> <snip>
>
>>
>>
>>> But how about `np.sum` itself? Right now, it is overridden by
>>> __array_function__ but classes without __array_function__ support can also
>>> override it through the method lookup and through __array_ufunc__.
>>>
>>> Would/should there be a point where we just have `sum = np.add.reduce`
>>> and drop other overrides? If so, how do we get there?
>>>
>>> One option might be start reversing the order in `_wrapreduction` - try
>>> `__array_ufunc__` if it is defined and only if that fails try the `.sum`
>>> method.
>>>
>>
>> Yes, I think we would need to do this sort of thing. It's a bit of
>> trouble, but probably doable with some decorator magic. It would indeed be
>> nice for sum() to eventually just be np.add.reduce, though to be honest I'm
>> not entirely sure it's worth the trouble of a long deprecation cycle --
>> people have been relying on the fall-back calling of methods for a long
>> time.
>>
>>
> I guess the one immediate question is whether `np.sum` and the like should
> be overridden by `__array_function__` at all, given that what should be the
> future recommended override already works.
>

I'm not sure I understand the rationale for this. Design consistency
matters. Right now the rule is simple: all ufuncs have __array_ufunc__, and
other functions __array_function__. Why keep on tweaking things for little
benefit?

Ralf



> (And, yes, arguably too late to change it now!)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190613/41bcccd0/attachment.html>