[Numpy-discussion] __array_function related regression for 1.17.0rc1

Stephan Hoyer shoyer at gmail.com
Tue Jul 2 02:33:26 EDT 2019


>
> Your suggestion on the issue to switch from typeerror to warning is, imho,
>> much better, as long as the warning contains a link to an issue/webpage
>> explaining what needs to happen. It's only because I've been vaguely aware
>> of the `__array_function__` discussions that I was able to diagnose
>> relatively quickly. The average user would be very confused by this code
>> break or by a warning, and be unsure of what they need to do to get rid of
>> the warning.
>>
>
>  This would work I think. It's not even a band-aid, it's probably the
> better design option because any sane library that implements
> __array_function__ will have a much smaller API surface than NumPy - and
> why forbid users from feeding array-like input to the rest of the NumPy
> functions?
>

This is addressed in the NEP, see bullet 1 under "Partial implementation of
NumPy's API":
http://www.numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api

My concern is that fallback coercion behavior makes it difficult to
reliably implement "strict" overrides of NumPy's API. Fallback coercion is
certainly useful for interactive use, but it isn't really appropriate for
libraries.

In contrast to putting this into NumPy, if a library like dask prefers to
issue warnings or even keep around fallback coercion indefinitely (not that
I would recommend it), they can do that by putting it in their
__array_function__ implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190701/87ed5c3e/attachment.html>


More information about the NumPy-Discussion mailing list