[Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

[Sebastian Berg]

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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200303/2e383086/attachment.sig>