On Mon, Jul 1, 2019 at 7:37 AM Juan Nunez-Iglesias <j...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
