On Tue, 2 Jul 2019, at 4:34 PM, Stephan Hoyer wrote:
> 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.

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 `__array_function__` 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.

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 
NumPy-Discussion mailing list

Reply via email to