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

[Andreas Mueller]

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 at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200408/874992ff/attachment-0001.html>