Thanks Joe, looks like everyone agrees: In text, NumPy it is.
-CHB On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington <j...@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.bar...@noaa.gov> > <chris.bar...@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 <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 <sho...@gmail.com> 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 <sho...@gmail.com> 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 <sho...@gmail.com> >> 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/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@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 >> > > > -- > > 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 > -- 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
