[Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

[Stephan Hoyer]

On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>
>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>>
>>
>>> The NEP currently does not say who this is meant for. Would you expect
>>> libraries like SciPy to adopt it for example?
>>>
>>> The NEP also (understandably) punts on the question of when something is
>>> a valid duck array. If you want this to be widely used, that will need an
>>> answer or at least some rough guidance though. For example, we would expect
>>> a duck array to have a mean() method, but probably not a ptp() method. A
>>> library author who wants to use np.duckarray() needs to know, because she
>>> can't test with all existing and future duck array implementations.
>>>
>>
>> I think this is covered in NEP-22 already.
>>
>
> It's not really. We discussed this briefly in the community call today,
> Peter said he will try to add some text.
>
> We should not add new functions to NumPy without indicating who is
> supposed to use this, and what need it fills / problem it solves. It seems
> pretty clear to me that it's mostly aimed at library authors rather than
> end users. And also that mature libraries like SciPy may not immediately
> adopt it, because it's too fuzzy - so it's new libraries first, mature
> libraries after the dust has settled a bit (I think).
>

I totally agree -- we definitely should clarify this in the docstring and
elsewhere in the docs. An example in the new doc page on "Writing custom
array containers" (https://numpy.org/devdocs/user/basics.dispatch.html)
would also probably be appropriate.


> As discussed there, I don't think NumPy is in a good position to pronounce
>> decisive APIs at this time. I would welcome efforts to try, but I don't
>> think that's essential for now.
>>
>
> There's no need to pronounce a decisive API that fully covers duck array.
> Note that RNumPy is an attempt in that direction (not a full one, but way
> better than nothing). In the NEP/docs, at least saying something along the
> lines of "if you implement this, we recommend the following strategy: check
> if a function is present in Dask, CuPy and Sparse. If so, it's reasonable
> to expect any duck array to work here. If not, we suggest you indicate in
> your docstring what kinds of duck arrays are accepted, or what properties
> they need to have". That's a spec by implementation, which is less than
> ideal but better than saying nothing.
>

OK, I agree here as well -- some guidance is better than nothing.

Two other minor notes on this NEP, concerning naming:
1. We should have a brief note on why we settled on the name "duck array".
Namely, as discussed in NEP-22, we don't love the "duck" jargon, but we
couldn't come up with anything better since NumPy already uses "array like"
and "any array" for different purposes.
2. The protocol should use *something* more clearly namespaced as NumPy
specific than __duckarray__. All the other special protocols NumPy defines
start with "__array_". That suggests either __array_duckarray__ (sounds a
little redundant) or __numpy_duckarray__ (which I like the look of, but is
a different from the existing protocols).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190807/8ba50c59/attachment-0001.html>