<div dir="ltr">Thanks Joe, looks like everyone agrees:<div><br></div><div>In text, NumPy it is.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington <<a href="mailto:jh@physics.ucf.edu">jh@physics.ucf.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <p>Here are my thoughts on textual capitalization (at first, I
      thought you wanted to raise money!):<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.<br>
    </p>
    <p> 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.<br>
    </p>
    <p>--jh--</p>
    <p><br>
    </p>
    <div class="gmail-m_-5893310023119580338moz-cite-prefix">On 9/16/19 9:09 PM, Chris Barker
      <a class="gmail-m_-5893310023119580338moz-txt-link-rfc2396E" href="mailto:chris.barker@noaa.gov" target="_blank"><chris.barker@noaa.gov></a> wrote:<br>
    </div>
    <br>
    <table class="gmail-m_-5893310023119580338header-part1" width="893" height="63" cellspacing="0" cellpadding="0" border="0">
      <tbody>
        <tr>
          <td><br>
          </td>
        </tr>
        <tr>
          <td><br>
          </td>
        </tr>
        <tr>
          <td><br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    <div class="gmail-m_-5893310023119580338moz-text-html" lang="x-unicode">
      <div dir="ltr">
        <div dir="ltr">Trivial note:
          <div><br>
          </div>
          <div>On the subject of naming things (spelling things??) --
            should it be:</div>
          <div><br>
          </div>
          <div>numpy</div>
          <div>or</div>
          <div>Numpy</div>
          <div>or</div>
          <div>NumPy</div>
          <div>?</div>
          <div><br>
          </div>
          <div>All three are in the draft NEP 30 ( mostly "NumPy", I
            noticed this when reading/copy editing the NEP) . Is there
            an "official" capitalization?</div>
          <div><br>
          </div>
          <div>My preference, would be to use "numpy", and where
            practicable, use a "computer" font -- i.e. ``numpy`` in RST.</div>
          <div><br>
          </div>
          <div>But if there is consensus already for anything else,
            that's fine, I'd just like to know what it is.</div>
          <div><br>
          </div>
          <div>-CHB</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 4:02
            AM Peter Andreas Entschev <<a href="mailto:peter@entschev.com" target="_blank">peter@entschev.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Apologies for the late
            reply. I've opened a new PR<br>
            <a href="https://github.com/numpy/numpy/pull/14257" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/pull/14257</a>
            with the changes requested<br>
            on clarifying the text. After reading the detailed
            description, I've<br>
            decided to add a subsection "Scope" to clarify the scope
            where NEP-30<br>
            would be useful. I think the inclusion of this new
            subsection<br>
            complements the "Detail description" forming a complete text
            w.r.t.<br>
            motivation of the NEP, but feel free to point out
            disagreements with<br>
            my suggestion. I've also added a new section "Usage"
            pointing out how<br>
            one would use duck array in replacement to np.asarray where
            relevant.<br>
            <br>
            Regarding the naming discussion, I must say I like the idea
            of keeping<br>
            the __array_ prefix, but it seems like that is going to be
            difficult<br>
            given that none of the existing ideas so far play very
            nicely with<br>
            that. So if the general consensus is to go with
            __numpy_like__, I<br>
            would also update the NEP to reflect that changes. FWIW, I<br>
            particularly neither like nor dislike __numpy_like__, but I
            don't have<br>
            any better suggestions than that or keeping the current
            naming.<br>
            <br>
            Best,<br>
            Peter<br>
            <br>
            On Thu, Aug 8, 2019 at 3:40 AM Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>>
            wrote:<br>
            ><br>
            ><br>
            ><br>
            > On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>>
            wrote:<br>
            >><br>
            >><br>
            >><br>
            >> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>>
            wrote:<br>
            >>><br>
            >>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers
            <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>>
            wrote:<br>
            >>>><br>
            >>>><br>
            >>>> On Mon, Aug 5, 2019 at 6:18 PM Stephan
            Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>>
            wrote:<br>
            >>>>><br>
            >>>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf
            Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br>
            >>>>><br>
            >>>>>><br>
            >>>>>> The NEP currently does not say who
            this is meant for. Would you expect libraries like SciPy to
            adopt it for example?<br>
            >>>>>><br>
            >>>>>> 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.<br>
            >>>>><br>
            >>>>><br>
            >>>>> I think this is covered in NEP-22
            already.<br>
            >>>><br>
            >>>><br>
            >>>> It's not really. We discussed this briefly
            in the community call today, Peter said he will try to add
            some text.<br>
            >>>><br>
            >>>> 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).<br>
            >>><br>
            >>><br>
            >>> 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" (<a href="https://numpy.org/devdocs/user/basics.dispatch.html" rel="noreferrer" target="_blank">https://numpy.org/devdocs/user/basics.dispatch.html</a>)
            would also probably be appropriate.<br>
            >>><br>
            >>>>><br>
            >>>>> 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.<br>
            >>>><br>
            >>>><br>
            >>>> 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.<br>
            >>><br>
            >>><br>
            >>> OK, I agree here as well -- some guidance is
            better than nothing.<br>
            >>><br>
            >>> Two other minor notes on this NEP, concerning
            naming:<br>
            >>> 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.<br>
            >>> 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).<br>
            >>><br>
            >><br>
            >> `__numpy_like__` ?<br>
            ><br>
            ><br>
            ><br>
            > 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".<br>
            ><br>
            >><br>
            >> Chuck<br>
            >> _______________________________________________<br>
            >> NumPy-Discussion mailing list<br>
            >> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
            >> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
            ><br>
            > _______________________________________________<br>
            > NumPy-Discussion mailing list<br>
            > <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
            > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
            _______________________________________________<br>
            NumPy-Discussion mailing list<br>
            <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
            <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr" class="gmail-m_-5893310023119580338gmail_signature"><br>
          Christopher Barker, Ph.D.<br>
          Oceanographer<br>
          <br>
          Emergency Response Division<br>
          NOAA/NOS/OR&R            (206) 526-6959   voice<br>
          7600 Sand Point Way NE   (206) 526-6329   fax<br>
          Seattle, WA  98115       (206) 526-6317   main reception<br>
          <br>
          <a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
      </div>
    </div>
  </div>

_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>