[Numpy-discussion] How to Capitalize numpy?
Chris Barker
chris.barker at noaa.gov
Mon Sep 16 17:46:44 EDT 2019
Thanks Joe, looks like everyone agrees:
In text, NumPy it is.
-CHB
On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington <jh at 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 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>
> <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>
> 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> wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>> >>>
>> >>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers <ralf.gommers at gmail.com>
>> wrote:
>> >>>>
>> >>>>
>> >>>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer <shoyer at gmail.com>
>> wrote:
>> >>>>>
>> >>>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers <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
>> >> https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion at python.org
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> _______________________________________________
>> NumPy-Discussion mailing list
>> 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
> _______________________________________________
> NumPy-Discussion mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190916/e3bd13ab/attachment-0001.html>
More information about the NumPy-Discussion
mailing list