On Fri, 2020-02-28 at 11:28 -0500, Allan Haldane wrote: > On 2/23/20 6:59 PM, Ralf Gommers wrote: > > One of the main rationales for the whole NEP, and the argument in > > multiple places > > ( > > https://numpy.org/neps/nep-0037-array-module.html#opt-in-vs-opt-out-for-users > > ) > > is that it's now opt-in while __array_function__ was opt-out. This > > isn't > > really true - the problem is simply *moved*, from the duck array > > libraries to the array-consuming libraries. The end user will still > > see > > the backwards incompatible change, with no way to turn it off. It > > will > > be easier with __array_module__ to warn users, but this should be > > expanded on in the NEP. > > Might it be possible to flip this NEP back to opt-out while keeping > the > nice simplifications and configurabile array-creation routines, > relative > to __array_function__? > > That is, what if we define two modules, "numpy" and "numpy_strict". > "numpy_strict" would raise an exception on duck-arrays defining > __array_module__ (as numpy currently does). "numpy" would be a > wrapper > around "numpy_strict" that decorates all numpy methods with a call to > "get_array_module(inputs).func(inputs)".
This would be possible, but I think we strongly leaned against the idea. Basically, if you have to opt-out, from a library perspective there may be `np.asarray` calls, which for example later call into C and expect arrays. So, I have large doubts that an opt-out solution works easily for library authors. Array function is opt-out, but effectively most clean library code already opted out... We had previously discussed the opposite, of having a namespace of implicit dispatching based on get_array_module, but if we keep array function around, I am not sure there is much reason for it. > > Then end-user code that did "import numpy as np" would accept > ducktypes > by default, while library developers who want to signal they don't > support ducktypes can opt-out by doing "import numpy_strict as np". > Issues with `np.as_array` seem mitigated compared to > __array_function__ > since that method would now be ducktype-aware. My tendency is that if we want to go there, we would need to push ahead with the `np.duckarray()` idea instead. To be clear: I currently very much prefer the get_array_module() idea. It just seems much cleaner for library authors, and they are the primary issue at the moment in my opinion. - Sebastian > -Allan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
