[Numpy-discussion] How to Capitalize numpy?
Joe Harrington
jh at physics.ucf.edu
Mon Sep 16 17:32:33 EDT 2019
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 <chris.barker at 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 at entschev.com <mailto:peter at 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 <shoyer at gmail.com
<mailto:shoyer at gmail.com>> wrote:
>
>
>
> On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris
<charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>> wrote:
>>
>>
>>
>> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <shoyer at gmail.com
<mailto:shoyer at gmail.com>> wrote:
>>>
>>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers
<ralf.gommers at gmail.com <mailto:ralf.gommers at gmail.com>> wrote:
>>>>
>>>>
>>>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer <shoyer at gmail.com
<mailto:shoyer at gmail.com>> wrote:
>>>>>
>>>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers
<ralf.gommers at gmail.com <mailto: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 <mailto:NumPy-Discussion at python.org>
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org <mailto:NumPy-Discussion at python.org>
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion at python.org <mailto:NumPy-Discussion at python.org>
https://mail.python.org/mailman/listinfo/numpy-discussion
--
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.Barker at noaa.gov <mailto:Chris.Barker at noaa.gov>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190916/64631405/attachment.html>
More information about the NumPy-Discussion
mailing list