<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 7:37 AM Juan Nunez-Iglesias <<a href="mailto:jni@fastmail.com">jni@fastmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div><br></div><div><br></div><div>On Mon, 1 Jul 2019, at 2:34 PM, Ralf Gommers wrote:<br></div><blockquote type="cite" id="gmail-m_3439132972926654114qt"><div dir="ltr"><div class="gmail-m_3439132972926654114qt-gmail_quote"><div>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?<br></div></div></div></blockquote><div><br></div><div>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.<br></div></div></blockquote><div><br></div><div>Yes, fair enough.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><div>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.<br></div></div></blockquote><div><br></div><div> 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?</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div><div><br></div></div></div>