Re: [Numpydiscussion] 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 lowercase 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 chris.barker@noaa.gov 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 <peter@entschev.com mailto:peter@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 NEP30 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 <shoyer@gmail.com mailto:shoyer@gmail.com> wrote: > > > > On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <charlesr.harris@gmail.com mailto:charlesr.harris@gmail.com> wrote: >> >> >> >> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <shoyer@gmail.com mailto:shoyer@gmail.com> wrote: >>> >>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers <ralf.gommers@gmail.com mailto:ralf.gommers@gmail.com> wrote: >>>> >>>> >>>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer <shoyer@gmail.com mailto:shoyer@gmail.com> wrote: >>>>> >>>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers <ralf.gommers@gmail.com mailto:ralf.gommers@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 NEP22 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 NEP22, 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 selfdescriptive than "duck array". > >> >> Chuck >> _______________________________________________ >> NumPyDiscussion mailing list >> NumPyDiscussion@python.org mailto:NumPyDiscussion@python.org >> https://mail.python.org/mailman/listinfo/numpydiscussion > > _______________________________________________ > NumPyDiscussion mailing list > NumPyDiscussion@python.org mailto:NumPyDiscussion@python.org > https://mail.python.org/mailman/listinfo/numpydiscussion _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@python.org mailto:NumPyDiscussion@python.org https://mail.python.org/mailman/listinfo/numpydiscussion
Thanks Joe, looks like everyone agrees:
In text, NumPy it is.
CHB
On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington jh@physics.ucf.edu 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 lowercase 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 chris.barker@noaa.gov chris.barker@noaa.gov 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 peter@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 NEP30 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 shoyer@gmail.com wrote:
On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <
charlesr.harris@gmail.com> wrote:
On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer shoyer@gmail.com wrote:
On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers ralf.gommers@gmail.com
wrote:
On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer shoyer@gmail.com
wrote:
> > On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers ralf.gommers@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 NEP22 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:
 We should have a brief note on why we settled on the name "duck
array". Namely, as discussed in NEP22, 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.
 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 selfdescriptive than "duck array".
Chuck _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@python.org https://mail.python.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@python.org https://mail.python.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@python.org https://mail.python.org/mailman/listinfo/numpydiscussion

Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception
Chris.Barker@noaa.gov _______________________________________________ NumPyDiscussion mailing list NumPyDiscussion@python.org https://mail.python.org/mailman/listinfo/numpydiscussion
Joe Harrington jh@physics.ucf.edu 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
participants (3)

Chris Barker

Joe Harrington

Pankaj Jangid