On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <charlesr.har...@gmail.com> wrote:
> > > On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <sho...@gmail.com> wrote: > >> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers <ralf.gomm...@gmail.com> >> wrote: >> >>> >>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer <sho...@gmail.com> wrote: >>> >>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers <ralf.gomm...@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@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion