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

[Charles R Harris]

On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> 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).
>
>
`__numpy_like__` ?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190807/d1d557bd/attachment.html>