Merge pull request #17999 from stefanv/Numpy-to-NumPy

Replace Numpy with NumPy

6 files changed, 39 insertions, 39 deletions

diff --git a/doc/neps/nep-0013-ufunc-overrides.rst b/doc/neps/nep-0013-ufunc-overrides.rst
index 698e45738..4a647e9d3 100644
--- a/doc/neps/nep-0013-ufunc-overrides.rst
+++ b/doc/neps/nep-0013-ufunc-overrides.rst
@@ -46,8 +46,8 @@ right behaviour, hence the change in name.)
 
 The ``__array_ufunc__`` as described below requires that any
 corresponding Python binary operations (``__mul__`` et al.) should be
-implemented in a specific way and be compatible with Numpy's ndarray
-semantics. Objects that do not satisfy this cannot override any Numpy
+implemented in a specific way and be compatible with NumPy's ndarray
+semantics. Objects that do not satisfy this cannot override any NumPy
 ufuncs.  We do not specify a future-compatible path by which this
 requirement can be relaxed --- any changes here require corresponding
 changes in 3rd party code.
@@ -132,7 +132,7 @@ However, this behavior is more confusing than useful, and having a
 :exc:`TypeError` would be preferable.
 
 This proposal will *not* resolve the issue with scipy.sparse matrices,
-which have multiplication semantics incompatible with numpy arrays.
+which have multiplication semantics incompatible with NumPy arrays.
 However, the aim is to enable writing other custom array types that have
 strictly ndarray compatible semantics.
 
@@ -246,7 +246,7 @@ three groups:
 - *Incompatible*: neither above nor below A; types for which no
   (indirect) upcasting is possible.
 
-Note that the legacy behaviour of numpy ufuncs is to try to convert
+Note that the legacy behaviour of NumPy ufuncs is to try to convert
 unknown objects to :class:`ndarray` via :func:`np.asarray`.  This is
 equivalent to placing :class:`ndarray` above these objects in the graph.
 Since we above defined :class:`ndarray` to return `NotImplemented` for
@@ -454,7 +454,7 @@ implements the following behavior:
 A class wishing to modify the interaction with :class:`ndarray` in
 binary operations therefore has two options:
 
-1. Implement ``__array_ufunc__`` and follow Numpy semantics for Python
+1. Implement ``__array_ufunc__`` and follow NumPy semantics for Python
    binary operations (see below).
 
 2. Set ``__array_ufunc__ = None``, and implement Python binary
@@ -678,7 +678,7 @@ NA     ``abs``      :func:`absolute`
 Future extensions to other functions
 ------------------------------------
 
-Some numpy functions could be implemented as (generalized) Ufunc, in
+Some NumPy functions could be implemented as (generalized) Ufunc, in
 which case it would be possible for them to be overridden by the
 ``__array_ufunc__`` method.  A prime candidate is :func:`~numpy.matmul`,
 which currently is not a Ufunc, but could be relatively easily be
diff --git a/doc/neps/nep-0023-backwards-compatibility.rst b/doc/neps/nep-0023-backwards-compatibility.rst
index 158f46273..c8bd7c180 100644
--- a/doc/neps/nep-0023-backwards-compatibility.rst
+++ b/doc/neps/nep-0023-backwards-compatibility.rst
@@ -156,7 +156,7 @@ Removing complete submodules
 This year there have been suggestions to consider removing some or all of
 ``numpy.distutils``, ``numpy.f2py``, ``numpy.linalg``, and ``numpy.random``.
 The motivation was that all these cost maintenance effort, and that they slow
-down work on the core of Numpy (ndarrays, dtypes and ufuncs).
+down work on the core of NumPy (ndarrays, dtypes and ufuncs).
 
 The impact on downstream libraries and users would be very large, and
 maintenance of these modules would still have to happen.  Therefore this is
diff --git a/doc/neps/nep-0025-missing-data-3.rst b/doc/neps/nep-0025-missing-data-3.rst
index ffe208c98..81045652e 100644
--- a/doc/neps/nep-0025-missing-data-3.rst
+++ b/doc/neps/nep-0025-missing-data-3.rst
@@ -62,7 +62,7 @@ values, (4) it is compatible with the common practice of using NaN to indicate
 missingness when working with floating point numbers, (5) the dtype is already
 a place where "weird things can happen" -- there are a wide variety of dtypes
 that don't act like ordinary numbers (including structs, Python objects,
-fixed-length strings, ...), so code that accepts arbitrary numpy arrays already
+fixed-length strings, ...), so code that accepts arbitrary NumPy arrays already
 has to be prepared to handle these (even if only by checking for them and
 raising an error). Therefore adding yet more new dtypes has less impact on
 extension authors than if we change the ndarray object itself.
@@ -96,7 +96,7 @@ for consistency.
 General strategy
 ================
 
-Numpy already has a general mechanism for defining new dtypes and slotting them
+NumPy already has a general mechanism for defining new dtypes and slotting them
 in so that they're supported by ndarrays, by the casting machinery, by ufuncs,
 and so on. In principle, we could implement NA-dtypes just using these existing
 interfaces. But we don't want to do that, because defining all those new ufunc
@@ -271,7 +271,7 @@ below.
 Casting
 -------
 
-FIXME: this really needs attention from an expert on numpy's casting rules. But
+FIXME: this really needs attention from an expert on NumPy's casting rules. But
 I can't seem to find the docs that explain how casting loops are looked up and
 decided between (e.g., if you're casting from dtype A to dtype B, which dtype's
 loops are used?), so I can't go into details. But those details are tricky and
@@ -338,7 +338,7 @@ Printing
 --------
 
 FIXME: There should be some sort of mechanism by which values which are NA are
-automatically repr'ed as NA, but I don't really understand how numpy printing
+automatically repr'ed as NA, but I don't really understand how NumPy printing
 works, so I'll let someone else fill in this section.
 
 Indexing
@@ -364,10 +364,10 @@ own global singleton.) So for now we stick to scalar indexing just returning
 Python API for generic NA support
 =================================
 
-NumPy will gain a global singleton called numpy.NA, similar to None, but with
+NumPy will gain a global singleton called ``numpy.NA``, similar to None, but with
 semantics reflecting its status as a missing value. In particular, trying to
 treat it as a boolean will raise an exception, and comparisons with it will
-produce numpy.NA instead of True or False. These basics are adopted from the
+produce ``numpy.NA`` instead of True or False. These basics are adopted from the
 behavior of the NA value in the R project. To dig deeper into the ideas,
 http://en.wikipedia.org/wiki/Ternary_logic#Kleene_logic provides a starting
 point.
@@ -453,8 +453,8 @@ The NEP also contains a proposal for a somewhat elaborate
 domain-specific-language for describing NA dtypes. I'm not sure how great an
 idea that is. (I have a bias against using strings as data structures, and find
 the already existing strings confusing enough as it is -- also, apparently the
-NEP version of numpy uses strings like 'f8' when printing dtypes, while my
-numpy uses object names like 'float64', so I'm not sure what's going on there.
+NEP version of NumPy uses strings like 'f8' when printing dtypes, while my
+NumPy uses object names like 'float64', so I'm not sure what's going on there.
 ``withNA(float64, arg1=value1)`` seems like a more pleasant way to print a
 dtype than "NA[f8,value1]", at least to me.) But if people want it, then cool.
 
diff --git a/doc/neps/nep-0027-zero-rank-arrarys.rst b/doc/neps/nep-0027-zero-rank-arrarys.rst
index 2d152234c..cb3972675 100644
--- a/doc/neps/nep-0027-zero-rank-arrarys.rst
+++ b/doc/neps/nep-0027-zero-rank-arrarys.rst
@@ -57,7 +57,7 @@ However there are some important differences:
 Motivation for Array Scalars
 ----------------------------
 
-Numpy's design decision to provide 0-d arrays and array scalars in addition to
+NumPy's design decision to provide 0-d arrays and array scalars in addition to
 native python types goes against one of the fundamental python design
 principles that there should be only one obvious way to do it.  In this section
 we will try to explain why it is necessary to have three different ways to
@@ -109,7 +109,7 @@ arrays to scalars were summarized as follows:
     are something like Python lists (which except for
     Object arrays they are not).
 
-Numpy implements a solution that is designed to have all the pros and none of the cons above.
+NumPy implements a solution that is designed to have all the pros and none of the cons above.
 
     Create Python scalar types for all of the 21 types and also
     inherit from the three that already exist. Define equivalent
diff --git a/doc/neps/nep-0029-deprecation_policy.rst b/doc/neps/nep-0029-deprecation_policy.rst
index 957674ee6..a50afcb98 100644
--- a/doc/neps/nep-0029-deprecation_policy.rst
+++ b/doc/neps/nep-0029-deprecation_policy.rst
@@ -1,7 +1,7 @@
 .. _NEP29:
 
 ==================================================================================
-NEP 29 — Recommend Python and Numpy version support as a community policy standard
+NEP 29 — Recommend Python and NumPy version support as a community policy standard
 ==================================================================================
 
 
@@ -124,14 +124,14 @@ Drop Schedule
 ::
 
   On next release, drop support for Python 3.5 (initially released on Sep 13, 2015)
-  On Jan 07, 2020 drop support for Numpy 1.14 (initially released on Jan 06, 2018)
+  On Jan 07, 2020 drop support for NumPy 1.14 (initially released on Jan 06, 2018)
   On Jun 23, 2020 drop support for Python 3.6 (initially released on Dec 23, 2016)
-  On Jul 23, 2020 drop support for Numpy 1.15 (initially released on Jul 23, 2018)
-  On Jan 13, 2021 drop support for Numpy 1.16 (initially released on Jan 13, 2019)
-  On Jul 26, 2021 drop support for Numpy 1.17 (initially released on Jul 26, 2019)
-  On Dec 22, 2021 drop support for Numpy 1.18 (initially released on Dec 22, 2019)
+  On Jul 23, 2020 drop support for NumPy 1.15 (initially released on Jul 23, 2018)
+  On Jan 13, 2021 drop support for NumPy 1.16 (initially released on Jan 13, 2019)
+  On Jul 26, 2021 drop support for NumPy 1.17 (initially released on Jul 26, 2019)
+  On Dec 22, 2021 drop support for NumPy 1.18 (initially released on Dec 22, 2019)
   On Dec 26, 2021 drop support for Python 3.7 (initially released on Jun 27, 2018)
-  On Jun 21, 2022 drop support for Numpy 1.19 (initially released on Jun 20, 2020)
+  On Jun 21, 2022 drop support for NumPy 1.19 (initially released on Jun 20, 2020)
   On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 14, 2019)
 
 
@@ -249,18 +249,18 @@ Code to generate support and drop schedule tables ::
 
   from datetime import datetime, timedelta
 
-  data = """Jan 15, 2017: Numpy 1.12
+  data = """Jan 15, 2017: NumPy 1.12
   Sep 13, 2015: Python 3.5
   Dec 23, 2016: Python 3.6
   Jun 27, 2018: Python 3.7
-  Jun 07, 2017: Numpy 1.13
-  Jan 06, 2018: Numpy 1.14
-  Jul 23, 2018: Numpy 1.15
-  Jan 13, 2019: Numpy 1.16
-  Jul 26, 2019: Numpy 1.17
+  Jun 07, 2017: NumPy 1.13
+  Jan 06, 2018: NumPy 1.14
+  Jul 23, 2018: NumPy 1.15
+  Jan 13, 2019: NumPy 1.16
+  Jul 26, 2019: NumPy 1.17
   Oct 14, 2019: Python 3.8
-  Dec 22, 2019: Numpy 1.18
-  Jun 20, 2020: Numpy 1.19
+  Dec 22, 2019: NumPy 1.18
+  Jun 20, 2020: NumPy 1.19
   """
 
   releases = []
@@ -284,7 +284,7 @@ Code to generate support and drop schedule tables ::
   py_major,py_minor = sorted([int(x) for x in r[2].split('.')] for r in releases if r[1] == 'Python')[-1]
   minpy = f"{py_major}.{py_minor+1}+"
 
-  num_major,num_minor = sorted([int(x) for x in r[2].split('.')] for r in releases if r[1] == 'Numpy')[-1]
+  num_major,num_minor = sorted([int(x) for x in r[2].split('.')] for r in releases if r[1] == 'NumPy')[-1]
   minnum = f"{num_major}.{num_minor+1}+"
 
   toprint_drop_dates = ['']
diff --git a/doc/neps/nep-0032-remove-financial-functions.rst b/doc/neps/nep-0032-remove-financial-functions.rst
index 1c3722f46..bf98a7467 100644
--- a/doc/neps/nep-0032-remove-financial-functions.rst
+++ b/doc/neps/nep-0032-remove-financial-functions.rst
@@ -174,19 +174,19 @@ References and footnotes
 .. [1] Financial functions,
    https://numpy.org/doc/1.17/reference/routines.financial.html
 
-.. [2] Numpy-discussion mailing list, "Simple financial functions for NumPy",
+.. [2] NumPy-Discussion mailing list, "Simple financial functions for NumPy",
    https://mail.python.org/pipermail/numpy-discussion/2008-April/032353.html
 
-.. [3] Numpy-discussion mailing list, "add xirr to numpy financial functions?",
+.. [3] NumPy-Discussion mailing list, "add xirr to numpy financial functions?",
    https://mail.python.org/pipermail/numpy-discussion/2009-May/042645.html
 
-.. [4] Numpy-discussion mailing list, "Definitions of pv, fv, nper, pmt, and rate",
+.. [4] NumPy-Discussion mailing list, "Definitions of pv, fv, nper, pmt, and rate",
    https://mail.python.org/pipermail/numpy-discussion/2009-June/043188.html
 
 .. [5] Get financial functions out of main namespace,
    https://github.com/numpy/numpy/issues/2880
 
-.. [6] Numpy-discussion mailing list, "Deprecation of financial routines",
+.. [6] NumPy-Discussion mailing list, "Deprecation of financial routines",
    https://mail.python.org/pipermail/numpy-discussion/2013-August/067409.html
 
 .. [7] ``component: numpy.lib.financial`` issues,
@@ -198,7 +198,7 @@ References and footnotes
 .. [9] Quansight-Labs/python-api-inspect,
    https://github.com/Quansight-Labs/python-api-inspect/
 
-.. [10] Numpy-discussion mailing list, "NEP 32: Remove the financial functions
+.. [10] NumPy-Discussion mailing list, "NEP 32: Remove the financial functions
    from NumPy"
    https://mail.python.org/pipermail/numpy-discussion/2019-September/079965.html
 
@@ -206,7 +206,7 @@ References and footnotes
    remove the financial functions.
    https://mail.google.com/mail/u/0/h/1w0mjgixc4rpe/?&th=16d5c38be45f77c4&q=nep+32&v=c&s=q
 
-.. [12] Numpy-discussion mailing list, "Proposal to accept NEP 32: Remove the
+.. [12] NumPy-Discussion mailing list, "Proposal to accept NEP 32: Remove the
    financial functions from NumPy"
    https://mail.python.org/pipermail/numpy-discussion/2019-September/080074.html