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

[Stephan Hoyer]

On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> 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__` ?
>


This could work, but I think we would also want to rename the NumPy
function itself to either np.like or np.numpy_like. The later is a little
redundant but definitely more self-descriptive than "duck array".


> Chuck
> _______________________________________________
> 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/20190807/782778ee/attachment-0001.html>