<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 1:45 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>On Tue, 2 Jul 2019, at 4:34 PM, Stephan Hoyer wrote:<br></div><blockquote type="cite" id="gmail-m_-3615683720186277667qt"><div dir="ltr"><div class="gmail-m_-3615683720186277667qt-gmail_quote"><div>This is addressed in the NEP, see bullet 1 under "Partial implementation of NumPy's API":<br></div><div><a href="http://www.numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api" target="_blank">http://www.numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api</a><br></div><div><br></div><div>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.<br></div></div></div></blockquote></div></blockquote><div><br></div><div>Do you mean "fallback coercion in NumPy itself", or "at all"? Right now there's lots of valid code around, e.g. `np.median(some_dask_array)`. Users will keep wanting to do that. Forcing everyone to write  `np.median(np.array(some_dask_array))` serves no purpose. So the coercion has to be somewhere. You're arguing that that's up to Dask et al I think?</div><div><br></div><div>Putting it in Dask right now still doesn't address Juan's backwards compat concern, but perhaps that could be bridged with a Dask bugfix release and some short-lived pain. </div><div><br></div><div>I'm not convinced that this shouldn't be fixed in NumPy though. Your concern "reliably implement "strict" overrides of NumPy's API" is a bit abstract. Overriding the _whole_ NumPy API is definitely undesirable. If we'd have a reference list somewhere about every function that is handled with __array_function__, then would that address your concern? Such a list could be auto-generated fairly easily.<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><blockquote type="cite" id="gmail-m_-3615683720186277667qt"><div dir="ltr"><div class="gmail-m_-3615683720186277667qt-gmail_quote"><div></div><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>I get the above concerns, and thanks for bringing them up, Stephan, as I'd only skimmed the NEP the first time around and missed them. Nevertheless, the fact is that the current behaviour breaks user code that was perfectly valid until NumPy 1.16, which seems, well, insane. So, warning for a few versions followed raising seems like the only way forward to me. The NEP explicitly states “We would like to gain experience with how <code class="gmail-m_-3615683720186277667docutils gmail-m_-3615683720186277667literal gmail-notranslate"><span class="gmail-m_-3615683720186277667pre">__array_function__</span></code> is
actually used before making decisions that would be difficult to roll back.” I think that this breakage *is* that experience, and the decision right now should be not to break user code with no warning period.<br></div></div></blockquote><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>I'm also wondering where the list of functions that must be implemented can be found, so that libraries like dask and CuPy can be sure that they have a complete implementation, and further typeerrors won't be raised with their arrays.<br></div></div></blockquote><div><br></div><div>This is one of the reasons I'm working on <a href="https://github.com/Quansight-Labs/rnumpy">https://github.com/Quansight-Labs/rnumpy</a>. It doesn't make sense for any library to copy the whole NumPy API, it's way too large with lots of stuff in there that's only there for backwards compat and has a better alternative or shouldn't be in NumPy in the first place.</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div><div><br></div></div></div>