Hey all.
Is there any update on this? Is there any input we can provide as users?
I'm not entirely sure where you are in the decision making process right
now :)
Cheers,
Andy
On 3/3/20 6:34 PM, Sebastian Berg wrote:
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
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
