[Numpy-discussion] How to Capitalize numpy?
Trivial note: On the subject of naming things (spelling things??) -- should it be: numpy or Numpy or NumPy ? All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when reading/copy editing the NEP) . Is there an "official" capitalization? My preference, would be to use "numpy", and where practicable, use a "computer" font -- i.e. ``numpy`` in RST. But if there is consensus already for anything else, that's fine, I'd just like to know what it is. -CHB On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev wrote: > Apologies for the late reply. I've opened a new PR > https://github.com/numpy/numpy/pull/14257 with the changes requested > on clarifying the text. After reading the detailed description, I've > decided to add a subsection "Scope" to clarify the scope where NEP-30 > would be useful. I think the inclusion of this new subsection > complements the "Detail description" forming a complete text w.r.t. > motivation of the NEP, but feel free to point out disagreements with > my suggestion. I've also added a new section "Usage" pointing out how > one would use duck array in replacement to np.asarray where relevant. > > Regarding the naming discussion, I must say I like the idea of keeping > the __array_ prefix, but it seems like that is going to be difficult > given that none of the existing ideas so far play very nicely with > that. So if the general consensus is to go with __numpy_like__, I > would also update the NEP to reflect that changes. FWIW, I > particularly neither like nor dislike __numpy_like__, but I don't have > any better suggestions than that or keeping the current naming. > > Best, > Peter > > On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer wrote: > > > > > > > > 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 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 namesp
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev wrote: > Apologies for the late reply. I've opened a new PR > https://github.com/numpy/numpy/pull/14257 with the changes requested > thanks! I've written a small PR on your PR: https://github.com/pentschev/numpy/pull/1 Essentially, other than typos and copy editing, I'm suggesting that a duck-array could choose to implement __array__ if it so chooses -- it should, of course, return an actual numpy array. I think this could be useful, as much code does require an actual numpy array, and only that class itself knows how best to convert to one. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Add a total_seconds() method to timedelta64?
I just noticed that there is no obvious way to convert a timedelta64 to seconds (or some other easy unit) as a number. The stdlib datetime.datetime has a .total_seconds() method for doing that. I think it's a handy thing to have. Looking at StackOverflow (and others), I see people suggesting things like: a_timedelta.astype(np.float) / 1e6 This seems a really bad idea, as it's assuming the timedelta is storing milliseconds. The "proper" way to do it also suggested: a_timedelta / np.timedelta64(1, 's') This is, in fact, a much better way to do it, and allows you to specify other units if you like: "ms"., "us", etc. There was semi-recently a discussion thread on python-ideas about adding other methods to datetime: (e.g. .total_hours, .total_minutes). That was pretty much rejected (or petered out anyway), and some argued that dividing by a timedelta of the unit you want is the "right" way to do it anyway (some argued that .total_seconds() never should have been added. Personally I understand the "correctness" of using united-division, but "practicality beats purity", and the discoverability of a method or two really makes it easier on folks. That being said, of folks don't want to add .total_seconds and the like -- we should add a bit to the docs about this, suggesting using the division approach. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to Capitalize numpy?
My answer to that: "NumPy". Reference: logo at the top of https://numpy.org/neps/index.html . In NEP-30 [1], I've used "NumPy" everywhere, except for references to code, repos, etc., where "numpy" is used. I see there's one occurrence of "Numpy", which was definitely a typo and I had not noticed it until now, but I will address this on a future update, thanks for pointing that out. [1] https://numpy.org/neps/nep-0030-duck-array-protocol.html On Mon, Sep 16, 2019 at 9:09 PM Chris Barker wrote: > > Trivial note: > > On the subject of naming things (spelling things??) -- should it be: > > numpy > or > Numpy > or > NumPy > ? > > All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when > reading/copy editing the NEP) . Is there an "official" capitalization? > > My preference, would be to use "numpy", and where practicable, use a > "computer" font -- i.e. ``numpy`` in RST. > > But if there is consensus already for anything else, that's fine, I'd just > like to know what it is. > > -CHB > > > > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev > wrote: >> >> Apologies for the late reply. I've opened a new PR >> https://github.com/numpy/numpy/pull/14257 with the changes requested >> on clarifying the text. After reading the detailed description, I've >> decided to add a subsection "Scope" to clarify the scope where NEP-30 >> would be useful. I think the inclusion of this new subsection >> complements the "Detail description" forming a complete text w.r.t. >> motivation of the NEP, but feel free to point out disagreements with >> my suggestion. I've also added a new section "Usage" pointing out how >> one would use duck array in replacement to np.asarray where relevant. >> >> Regarding the naming discussion, I must say I like the idea of keeping >> the __array_ prefix, but it seems like that is going to be difficult >> given that none of the existing ideas so far play very nicely with >> that. So if the general consensus is to go with __numpy_like__, I >> would also update the NEP to reflect that changes. FWIW, I >> particularly neither like nor dislike __numpy_like__, but I don't have >> any better suggestions than that or keeping the current naming. >> >> Best, >> Peter >> >> On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer wrote: >> > >> > >> > >> > 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 >> >
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
What would be the use case for a duck-array to implement __array__ and return a NumPy array? Unless I'm missing something, this seems redundant and one should just use array/asarray functions then. This would also prevent error-handling, what if the developer intentionally wants a NumPy-like array (e.g., the original array passed to the duckarray function) or an exception (instead of coercing to a NumPy array)? On Mon, Sep 16, 2019 at 9:25 PM Chris Barker wrote: > > > > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev > wrote: >> >> Apologies for the late reply. I've opened a new PR >> https://github.com/numpy/numpy/pull/14257 with the changes requested > > > thanks! > > I've written a small PR on your PR: > > https://github.com/pentschev/numpy/pull/1 > > Essentially, other than typos and copy editing, I'm suggesting that a > duck-array could choose to implement __array__ if it so chooses -- it should, > of course, return an actual numpy array. > > I think this could be useful, as much code does require an actual numpy > array, and only that class itself knows how best to convert to one. > > -CHB > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > ___ > 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
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev wrote: > What would be the use case for a duck-array to implement __array__ and > return a NumPy array? Unless I'm missing something, this seems > redundant and one should just use array/asarray functions then. This > would also prevent error-handling, what if the developer intentionally > wants a NumPy-like array (e.g., the original array passed to the > duckarray function) or an exception (instead of coercing to a NumPy > array)? > Dask arrays are a good example. They will want to implement __duck_array__ (or whatever we call it) because they support duck typed versions of NumPy operation. They also (already) implement __array__, so they can converted into NumPy arrays as a fallback. This is convenient for moderately sized dask arrays, e.g., so you can pass one into a matplotlib function. > > On Mon, Sep 16, 2019 at 9:25 PM Chris Barker > wrote: > > > > > > > > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev < > pe...@entschev.com> wrote: > >> > >> Apologies for the late reply. I've opened a new PR > >> https://github.com/numpy/numpy/pull/14257 with the changes requested > > > > > > thanks! > > > > I've written a small PR on your PR: > > > > https://github.com/pentschev/numpy/pull/1 > > > > Essentially, other than typos and copy editing, I'm suggesting that a > duck-array could choose to implement __array__ if it so chooses -- it > should, of course, return an actual numpy array. > > > > I think this could be useful, as much code does require an actual numpy > array, and only that class itself knows how best to convert to one. > > > > -CHB > > > > -- > > > > Christopher Barker, Ph.D. > > Oceanographer > > > > Emergency Response Division > > NOAA/NOS/OR&R(206) 526-6959 voice > > 7600 Sand Point Way NE (206) 526-6329 fax > > Seattle, WA 98115 (206) 526-6317 main reception > > > > chris.bar...@noaa.gov > > ___ > > 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 > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to Capitalize numpy?
On Mon, Sep 16, 2019 at 1:42 PM Peter Andreas Entschev wrote: > My answer to that: "NumPy". Reference: logo at the top of > https://numpy.org/neps/index.html . > Yes, NumPy is the right capitalization > In NEP-30 [1], I've used "NumPy" everywhere, except for references to > code, repos, etc., where "numpy" is used. I see there's one occurrence > of "Numpy", which was definitely a typo and I had not noticed it until > now, but I will address this on a future update, thanks for pointing > that out. > > [1] https://numpy.org/neps/nep-0030-duck-array-protocol.html > > On Mon, Sep 16, 2019 at 9:09 PM Chris Barker > wrote: > > > > Trivial note: > > > > On the subject of naming things (spelling things??) -- should it be: > > > > numpy > > or > > Numpy > > or > > NumPy > > ? > > > > All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when > reading/copy editing the NEP) . Is there an "official" capitalization? > > > > My preference, would be to use "numpy", and where practicable, use a > "computer" font -- i.e. ``numpy`` in RST. > > > > But if there is consensus already for anything else, that's fine, I'd > just like to know what it is. > > > > -CHB > > > > > > > > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev < > pe...@entschev.com> wrote: > >> > >> Apologies for the late reply. I've opened a new PR > >> https://github.com/numpy/numpy/pull/14257 with the changes requested > >> on clarifying the text. After reading the detailed description, I've > >> decided to add a subsection "Scope" to clarify the scope where NEP-30 > >> would be useful. I think the inclusion of this new subsection > >> complements the "Detail description" forming a complete text w.r.t. > >> motivation of the NEP, but feel free to point out disagreements with > >> my suggestion. I've also added a new section "Usage" pointing out how > >> one would use duck array in replacement to np.asarray where relevant. > >> > >> Regarding the naming discussion, I must say I like the idea of keeping > >> the __array_ prefix, but it seems like that is going to be difficult > >> given that none of the existing ideas so far play very nicely with > >> that. So if the general consensus is to go with __numpy_like__, I > >> would also update the NEP to reflect that changes. FWIW, I > >> particularly neither like nor dislike __numpy_like__, but I don't have > >> any better suggestions than that or keeping the current naming. > >> > >> Best, > >> Peter > >> > >> On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer wrote: > >> > > >> > > >> > > >> > 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 > 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 < > 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
Re: [Numpy-discussion] How to Capitalize numpy?
Here are my thoughts on textual capitalization (at first, I thought you wanted to raise money!): We all agree that in code, it is "numpy". If you don't use that, it throws an error. If, in text, we keep "numpy" with a forced lower-case letter at the start, it is just one more oddball to remember. It is even weirder in titles and the beginnings of sentences. I'd strongly like not to be weird that way. A few packages are, it's annoying, and it doesn't much earn them any goodwill. The default among people who are not "in the know" will be to do what they're used to. Let's give them what they're used to, a proper noun with initial (at least) capital. Likewise, I object to preferring a particular font. What fonts to use for the names of things like software packages is a decision for publications to make. A journal or manual might make fine distinctions and demand several different, specific fonts, while a popular publication might prefer not to do that. Leave the typesetting to the editors of the publications. We can certainly adopt a standard for our publications (docs, web pages, etc.), but we should state explicitly that others can do as they like. It's not an acronym, so that leaves the options of "Numpy" and "NumPy". It would be great, easy to remember, consistent for others, etc., if NumPy and SciPy were capitalized the same way and were pronounced the same (I still occasionally hear "numpee"). So, I would favor "NumPy" to go along with "SciPy", and let the context choose the font. --jh-- On 9/16/19 9:09 PM, Chris Barker wrote: Trivial note: On the subject of naming things (spelling things??) -- should it be: numpy or Numpy or NumPy ? All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when reading/copy editing the NEP) . Is there an "official" capitalization? My preference, would be to use "numpy", and where practicable, use a "computer" font -- i.e. ``numpy`` in RST. But if there is consensus already for anything else, that's fine, I'd just like to know what it is. -CHB On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev mailto:pe...@entschev.com>> wrote: Apologies for the late reply. I've opened a new PR https://github.com/numpy/numpy/pull/14257 with the changes requested on clarifying the text. After reading the detailed description, I've decided to add a subsection "Scope" to clarify the scope where NEP-30 would be useful. I think the inclusion of this new subsection complements the "Detail description" forming a complete text w.r.t. motivation of the NEP, but feel free to point out disagreements with my suggestion. I've also added a new section "Usage" pointing out how one would use duck array in replacement to np.asarray where relevant. Regarding the naming discussion, I must say I like the idea of keeping the __array_ prefix, but it seems like that is going to be difficult given that none of the existing ideas so far play very nicely with that. So if the general consensus is to go with __numpy_like__, I would also update the NEP to reflect that changes. FWIW, I particularly neither like nor dislike __numpy_like__, but I don't have any better suggestions than that or keeping the current naming. Best, Peter On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer mailto:sho...@gmail.com>> wrote: > > > > On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris mailto:charlesr.har...@gmail.com>> wrote: >> >> >> >> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer mailto:sho...@gmail.com>> wrote: >>> >>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers mailto:ralf.gomm...@gmail.com>> wrote: On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer mailto:sho...@gmail.com>> wrote: > > On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers mailto: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 au
Re: [Numpy-discussion] How to Capitalize numpy?
got it, thanks. I've fixed that typo in a PR I"m working on , too. -CHB On Mon, Sep 16, 2019 at 2:41 PM Ralf Gommers wrote: > > > On Mon, Sep 16, 2019 at 1:42 PM Peter Andreas Entschev > wrote: > >> My answer to that: "NumPy". Reference: logo at the top of >> https://numpy.org/neps/index.html . >> > > Yes, NumPy is the right capitalization > > > >> In NEP-30 [1], I've used "NumPy" everywhere, except for references to >> code, repos, etc., where "numpy" is used. I see there's one occurrence >> of "Numpy", which was definitely a typo and I had not noticed it until >> now, but I will address this on a future update, thanks for pointing >> that out. >> >> [1] https://numpy.org/neps/nep-0030-duck-array-protocol.html >> >> On Mon, Sep 16, 2019 at 9:09 PM Chris Barker >> wrote: >> > >> > Trivial note: >> > >> > On the subject of naming things (spelling things??) -- should it be: >> > >> > numpy >> > or >> > Numpy >> > or >> > NumPy >> > ? >> > >> > All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when >> reading/copy editing the NEP) . Is there an "official" capitalization? >> > >> > My preference, would be to use "numpy", and where practicable, use a >> "computer" font -- i.e. ``numpy`` in RST. >> > >> > But if there is consensus already for anything else, that's fine, I'd >> just like to know what it is. >> > >> > -CHB >> > >> > >> > >> > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev < >> pe...@entschev.com> wrote: >> >> >> >> Apologies for the late reply. I've opened a new PR >> >> https://github.com/numpy/numpy/pull/14257 with the changes requested >> >> on clarifying the text. After reading the detailed description, I've >> >> decided to add a subsection "Scope" to clarify the scope where NEP-30 >> >> would be useful. I think the inclusion of this new subsection >> >> complements the "Detail description" forming a complete text w.r.t. >> >> motivation of the NEP, but feel free to point out disagreements with >> >> my suggestion. I've also added a new section "Usage" pointing out how >> >> one would use duck array in replacement to np.asarray where relevant. >> >> >> >> Regarding the naming discussion, I must say I like the idea of keeping >> >> the __array_ prefix, but it seems like that is going to be difficult >> >> given that none of the existing ideas so far play very nicely with >> >> that. So if the general consensus is to go with __numpy_like__, I >> >> would also update the NEP to reflect that changes. FWIW, I >> >> particularly neither like nor dislike __numpy_like__, but I don't have >> >> any better suggestions than that or keeping the current naming. >> >> >> >> Best, >> >> Peter >> >> >> >> On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer wrote: >> >> > >> >> > >> >> > >> >> > 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 >> 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 >> 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
Re: [Numpy-discussion] How to Capitalize numpy?
Thanks Joe, looks like everyone agrees: In text, NumPy it is. -CHB On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington wrote: > Here are my thoughts on textual capitalization (at first, I thought you > wanted to raise money!): > > We all agree that in code, it is "numpy". If you don't use that, it > throws an error. If, in text, we keep "numpy" with a forced lower-case > letter at the start, it is just one more oddball to remember. It is even > weirder in titles and the beginnings of sentences. I'd strongly like not > to be weird that way. A few packages are, it's annoying, and it doesn't > much earn them any goodwill. The default among people who are not "in the > know" will be to do what they're used to. Let's give them what they're > used to, a proper noun with initial (at least) capital. > > Likewise, I object to preferring a particular font. What fonts to use for > the names of things like software packages is a decision for publications > to make. A journal or manual might make fine distinctions and demand > several different, specific fonts, while a popular publication might prefer > not to do that. Leave the typesetting to the editors of the publications. > We can certainly adopt a standard for our publications (docs, web pages, > etc.), but we should state explicitly that others can do as they like. > > It's not an acronym, so that leaves the options of "Numpy" and "NumPy". > It would be great, easy to remember, consistent for others, etc., if NumPy > and SciPy were capitalized the same way and were pronounced the same (I > still occasionally hear "numpee"). So, I would favor "NumPy" to go along > with "SciPy", and let the context choose the font. > > --jh-- > > > On 9/16/19 9:09 PM, Chris Barker > wrote: > > > > > > Trivial note: > > On the subject of naming things (spelling things??) -- should it be: > > numpy > or > Numpy > or > NumPy > ? > > All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when > reading/copy editing the NEP) . Is there an "official" capitalization? > > My preference, would be to use "numpy", and where practicable, use a > "computer" font -- i.e. ``numpy`` in RST. > > But if there is consensus already for anything else, that's fine, I'd just > like to know what it is. > > -CHB > > > > On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev > wrote: > >> Apologies for the late reply. I've opened a new PR >> https://github.com/numpy/numpy/pull/14257 with the changes requested >> on clarifying the text. After reading the detailed description, I've >> decided to add a subsection "Scope" to clarify the scope where NEP-30 >> would be useful. I think the inclusion of this new subsection >> complements the "Detail description" forming a complete text w.r.t. >> motivation of the NEP, but feel free to point out disagreements with >> my suggestion. I've also added a new section "Usage" pointing out how >> one would use duck array in replacement to np.asarray where relevant. >> >> Regarding the naming discussion, I must say I like the idea of keeping >> the __array_ prefix, but it seems like that is going to be difficult >> given that none of the existing ideas so far play very nicely with >> that. So if the general consensus is to go with __numpy_like__, I >> would also update the NEP to reflect that changes. FWIW, I >> particularly neither like nor dislike __numpy_like__, but I don't have >> any better suggestions than that or keeping the current naming. >> >> Best, >> Peter >> >> On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer wrote: >> > >> > >> > >> > 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 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
Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
On Mon, Sep 16, 2019 at 1:46 PM Peter Andreas Entschev wrote: > What would be the use case for a duck-array to implement __array__ and > return a NumPy array? some users need a genuine, actual numpy array (for passing to Cyton code, for example). if __array__ is not implemented, how can they get that from an array-like object?? Only the author of the array-like object knows how best to make a numpy array out of it. Unless I'm missing something, this seems > redundant and one should just use array/asarray functions then. but if the object does not impliment __array__, then user's can't use the array/asarray functions! > This > would also prevent error-handling, what if the developer intentionally > wants a NumPy-like array (e.g., the original array passed to the > duckarray function) or an exception (instead of coercing to a NumPy > array)? > I'm really confused now -- if a end-user wants a duckarray, they should call duckarray() -- if they want an actual numpy array, they should call .asarray(). Why would anyone want an Exception? If you don't want an array, then don't call asarray() If you call duckarray(), and the object has not implemented __duckarray__, then you will get an exception -- whoch you should. If you call __array_, and __array__ has not been implimented, then you will get an exception. what is the potential problem here? Which makes me think -- why should Duck arrays ever implement an __array__ method that raises an Exception? why not jsut not impliment it? (unless you wantt o add some helpful error message -- which I did for the example in my PR. (PR to the numpy repo in progress) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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 Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote: > On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev > wrote: > >> What would be the use case for a duck-array to implement __array__ and >> return a NumPy array? > > > Dask arrays are a good example. They will want to implement __duck_array__ > (or whatever we call it) because they support duck typed versions of NumPy > operation. They also (already) implement __array__, so they can converted > into NumPy arrays as a fallback. This is convenient for moderately sized > dask arrays, e.g., so you can pass one into a matplotlib function. > Exactly. And I have implemented __array__ in classes that are NOT duck arrays at all (an image class, for instance). But I also can see wanting to support both: use me as a duck array and convert me into a proper numpy array. OK -- looking again at the NEP, I see this suggested implementation: def duckarray(array_like): if hasattr(array_like, '__duckarray__'): return array_like.__duckarray__() return np.asarray(array_like) So I see the point now, if a user wants a duck array -- they may not want to accidentally coerce this object to a real array (potentially expensive). but in this case, asarray() will only get called (and thus __array__ will only get called), if __duckarray__ is not implemented. So the only reason to impliment __array__ and raise and Exception is so that users will get that exception is the specifically call asarray() -- why should they get that?? I'm working on a PR with suggestion for this. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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
OK -- I *finally* got it: when you pass an arbitrary object into np.asarray(), it will create an array object scalar with the object in it. So yes, I can see that you may want to raise a TypeError instead, so that users don't get an object array scalar when they wre expecting to get an array-like object. So it's probably a good idea to recommend that when a class implements __dauckarray__ that it also implements __array__, which can either raise an exception or return and ndarray. -CHB On Mon, Sep 16, 2019 at 3:11 PM Chris Barker wrote: > On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote: > >> On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev < >> pe...@entschev.com> wrote: >> >>> What would be the use case for a duck-array to implement __array__ and >>> return a NumPy array? >> >> > >> Dask arrays are a good example. They will want to implement >> __duck_array__ (or whatever we call it) because they support duck typed >> versions of NumPy operation. They also (already) implement __array__, so >> they can converted into NumPy arrays as a fallback. This is convenient for >> moderately sized dask arrays, e.g., so you can pass one into a matplotlib >> function. >> > > Exactly. > > And I have implemented __array__ in classes that are NOT duck arrays at > all (an image class, for instance). But I also can see wanting to support > both: > > use me as a duck array > and > convert me into a proper numpy array. > > OK -- looking again at the NEP, I see this suggested implementation: > > def duckarray(array_like): > if hasattr(array_like, '__duckarray__'): > return array_like.__duckarray__() > return np.asarray(array_like) > > So I see the point now, if a user wants a duck array -- they may not want > to accidentally coerce this object to a real array (potentially expensive). > > but in this case, asarray() will only get called (and thus __array__ will > only get called), if __duckarray__ is not implemented. So the only reason > to impliment __array__ and raise and Exception is so that users will get > that exception is the specifically call asarray() -- why should they get > that?? > > I'm working on a PR with suggestion for this. > > -CHB > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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
Here's a PR with a different dicsussion of __array__: https://github.com/numpy/numpy/pull/14529 -CHB On Mon, Sep 16, 2019 at 3:23 PM Chris Barker wrote: > OK -- I *finally* got it: > > when you pass an arbitrary object into np.asarray(), it will create an > array object scalar with the object in it. > > So yes, I can see that you may want to raise a TypeError instead, so that > users don't get an object array scalar when they wre expecting to get an > array-like object. > > So it's probably a good idea to recommend that when a class implements > __dauckarray__ that it also implements __array__, which can either raise an > exception or return and ndarray. > > -CHB > > > On Mon, Sep 16, 2019 at 3:11 PM Chris Barker > wrote: > >> On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote: >> >>> On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev < >>> pe...@entschev.com> wrote: >>> What would be the use case for a duck-array to implement __array__ and return a NumPy array? >>> >>> >> >>> Dask arrays are a good example. They will want to implement >>> __duck_array__ (or whatever we call it) because they support duck typed >>> versions of NumPy operation. They also (already) implement __array__, so >>> they can converted into NumPy arrays as a fallback. This is convenient for >>> moderately sized dask arrays, e.g., so you can pass one into a matplotlib >>> function. >>> >> >> Exactly. >> >> And I have implemented __array__ in classes that are NOT duck arrays at >> all (an image class, for instance). But I also can see wanting to support >> both: >> >> use me as a duck array >> and >> convert me into a proper numpy array. >> >> OK -- looking again at the NEP, I see this suggested implementation: >> >> def duckarray(array_like): >> if hasattr(array_like, '__duckarray__'): >> return array_like.__duckarray__() >> return np.asarray(array_like) >> >> So I see the point now, if a user wants a duck array -- they may not want >> to accidentally coerce this object to a real array (potentially expensive). >> >> but in this case, asarray() will only get called (and thus __array__ will >> only get called), if __duckarray__ is not implemented. So the only reason >> to impliment __array__ and raise and Exception is so that users will get >> that exception is the specifically call asarray() -- why should they get >> that?? >> >> I'm working on a PR with suggestion for this. >> >> -CHB >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to Capitalize numpy?
Joe Harrington writes: > It's not an acronym, so that leaves the options of "Numpy" and > "NumPy". It would be great, easy to remember, consistent for others, > etc., if NumPy and SciPy were capitalized the same way and were > pronounced the same (I still occasionally hear "numpee"). So, I would > favor "NumPy" to go along with "SciPy", and let the context choose the > font. > "NumPy" is perfect capitalization. It looks beautiful in pure text. For programming, "numpy" is good. Most of the time I import it as "np". -- Regards, Pankaj Jangid ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] keeping all meeting notes and docs in new repo?
Hi all, I like the idea of having a new repo containing meeting minutes and docs. Regards, ZJ On Sun, Sep 15, 2019 at 5:26 PM Ralf Gommers wrote: > Hi all, > > We have had community calls for quite a while, the minutes of which are > kept in https://github.com/BIDS-numpy/docs. That's quite hard to > discover, it would be better if those lived under the NumPy GitHub org. > Also, we have minutes from Season of Docs and website redesign calls, plus > occasionally some other docs (e.g. the roadmap drafts were on hackmd.io). > > Would it make sense to add a new repo to contain all such meeting minutes > and docs? Presentations and proposals may make sense to add as well - > several people have given presentations or submitted proposals on behalf of > the project. > > Inessa also suggested to enable HackMD Hub (see > https://hackmd.io/c/tutorials/%2Fs%2Flink-with-github) so we get > automatic versioning for some HackMD documents. I haven't used it before, > but it looks good. > > Thoughts? > > Cheers, > Ralf > > > > ___ > 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
