Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: > On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers > 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). 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. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Season of Docs - welcome Anne, Maja, Brandon
On Tue, Aug 6, 2019 at 4:46 PM Ralf Gommers wrote: > Hi all, > > Google has announced the Season of Docs participants for this year [1]. We > had a lot of excellent candidates and had to make some hard choices. We > applied for extra slots, but unfortunately didn't win the lottery for > those; we got one slot for NumPy and one for SciPy. We chose the projects > of Anne for NumPy and Maja for SciPy: > > Anne Bonner, "Making "The Basics" a Little More Basic: Improving the > Introductory NumPy Sections" [2] > > Maja Gwozdz, "User-oriented documentation and thorough restructuring" [3] > > That's not all though. There was some space left in the budget of the > NumPy BIDS grant, and Stéfan has reserved that so we can accept more > writers and provide them the same mentoring and funding as they would have > gotten through GSoD. We could only start the conversations about that once > Google made its decisions, so a further announcement will follow. However, > we already have one extra project confirmed, from Brandon: > > Brandon David, "Improve the documentation of scipy.stats" (project details > to be published). > Happy to announce that we have a fourth participant: Shekhar Rajak, "numpy.org redesign and high level documentation restructuring for end user focus" Welcome Shekhar! I will send out a poll to find a good time for everyone for a kickoff call. > Our intent is to build a documentation team with multiple writers and > mentors interacting and able to help each other out. And all of this will > also interact with the numpy.org website redesign and the people putting > energy into that:) > Here is the poll link: https://doodle.com/poll/skgbk74gsg8zpziu. I hope we can find a time that works for everyone - we're split over all US timezones, Europe and India. So it's going to be early morning or late evening somewhere. Sending this out in public, so anyone who wants to participate is welcome to join. I've Bcc'd all participants and mentors, to make sure they see this. Cheers, Ralf > > I'm very happy to welcome Anne, Maja and Brandon! > > Cheers, > Ralf > > > [1] https://developers.google.com/season-of-docs/docs/participants/ > [2] > https://developers.google.com/season-of-docs/docs/participants/project-numpy > [3] > https://developers.google.com/season-of-docs/docs/participants/project-scipy > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers wrote: > > On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: > >> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers >> 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-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer wrote: > On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers > wrote: > >> >> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: >> >>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers >>> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris wrote: > > > On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer wrote: > >> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers >> wrote: >> >>> >>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: >>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers 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
