[Numpy-discussion] __array_function related regression for 1.17.0rc1

[Ralf Gommers]

On Mon, Jul 1, 2019 at 7:37 AM Juan Nunez-Iglesias <jni at fastmail.com> wrote:

>
>
> On Mon, 1 Jul 2019, at 2:34 PM, Ralf Gommers wrote:
>
> This issue is not very surprising - __array_function__ is going to have a
> fair bit of backwards compat impact for people who were relying on feeding
> all sorts of stuff into numpy functions that previously got converted with
> asarray. At this point Dask is the main worry, followed by CuPy and
> pydata/sparse. All those libraries have very responsive maintainers.
> Perhaps we should just try to get these issues fixed asap in those
> libraries instead?
>
>
> Fixing them is not sufficient, because many people are still going to end
> up with broken code unless they are bleeding-edge with everything. It's
> best to minimise the number of forbidden version combinations.
>

Yes, fair enough.


> 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?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190701/7db83925/attachment-0001.html>