[Numpy-discussion] How to Capitalize numpy?

Mon Sep 16 17:40:10 EDT 2019

On Mon, Sep 16, 2019 at 1:42 PM Peter Andreas Entschev <peter at entschev.com>
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 <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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190916/ab6b77e5/attachment-0001.html>