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-user... ) 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