Merge pull request #19920 from DimitriPapadopoulos/codespell-neps

DOC: Fix typos in NEPs, found by codespell

14 files changed, 22 insertions, 22 deletions

diff --git a/doc/neps/nep-0010-new-iterator-ufunc.rst b/doc/neps/nep-0010-new-iterator-ufunc.rst
index fd89e96b4..67177d30b 100644
--- a/doc/neps/nep-0010-new-iterator-ufunc.rst
+++ b/doc/neps/nep-0010-new-iterator-ufunc.rst
@@ -1545,7 +1545,7 @@ Functions For Iteration
 ``npy_intp *NpyIter_GetIndexPtr(NpyIter *iter)``
 
     This gives back a pointer to the index being tracked, or NULL
-    if no index is being tracked.  It is only useable if one of
+    if no index is being tracked.  It is only usable if one of
     the flags ``NPY_ITER_C_INDEX`` or ``NPY_ITER_F_INDEX``
     were specified during construction.
 
diff --git a/doc/neps/nep-0012-missing-data.rst b/doc/neps/nep-0012-missing-data.rst
index c590e8fc3..4775ea18b 100644
--- a/doc/neps/nep-0012-missing-data.rst
+++ b/doc/neps/nep-0012-missing-data.rst
@@ -903,7 +903,7 @@ before it will allow NA-masked arrays to flow through.
 https://docs.scipy.org/doc/numpy/reference/c-api.array.html#NPY_ARRAY_ALLOWNA
 
 Code which does not follow this advice, and instead just calls PyArray_Check() to verify
-its an ndarray and checks some flags, will silently produce incorrect results. This style
+it is an ndarray and checks some flags, will silently produce incorrect results. This style
 of code does not provide any opportunity for numpy to say "hey, this array is special",
 so also is not compatible with future ideas of lazy evaluation, derived dtypes, etc.
 
@@ -963,7 +963,7 @@ The first version to implement is the array masks, because it is
 the more general approach. The mask itself is an array, but since
 it is intended to never be directly accessible from Python, it won't
 be a full ndarray itself. The mask always has the same shape as
-the array it's attached to, so it doesn't need its own shape. For
+the array it is attached to, so it doesn't need its own shape. For
 an array with a struct dtype, however, the mask will have a different
 dtype than just a straight bool, so it does need its own dtype.
 This gives us the following additions to the PyArrayObject::
diff --git a/doc/neps/nep-0018-array-function-protocol.rst b/doc/neps/nep-0018-array-function-protocol.rst
index 0dcb0ff7e..f4c21446b 100644
--- a/doc/neps/nep-0018-array-function-protocol.rst
+++ b/doc/neps/nep-0018-array-function-protocol.rst
@@ -15,8 +15,8 @@ NEP 18 — A dispatch mechanism for NumPy's high level array functions
 :Updated: 2019-05-25
 :Resolution: https://mail.python.org/pipermail/numpy-discussion/2018-August/078493.html
 
-Abstact
--------
+Abstract
+--------
 
 We propose the ``__array_function__`` protocol, to allow arguments of NumPy
 functions to define how that function operates on them. This will allow
diff --git a/doc/neps/nep-0020-gufunc-signature-enhancement.rst b/doc/neps/nep-0020-gufunc-signature-enhancement.rst
index 961cf4584..80ee75f5f 100644
--- a/doc/neps/nep-0020-gufunc-signature-enhancement.rst
+++ b/doc/neps/nep-0020-gufunc-signature-enhancement.rst
@@ -112,7 +112,7 @@ have a summary of all flags. This could possibly be stored in ``core_enabled``
 but specific flags indicating whether or not a gufunc uses fixed, flexible, or
 broadcastable dimensions.
 
-With the above, the formal defition of the syntax would become [4]_::
+With the above, the formal definition of the syntax would become [4]_::
 
   <Signature>            ::= <Input arguments> "->" <Output arguments>
   <Input arguments>      ::= <Argument list>
diff --git a/doc/neps/nep-0031-uarray.rst b/doc/neps/nep-0031-uarray.rst
index 47d4bdd37..b4ec94077 100644
--- a/doc/neps/nep-0031-uarray.rst
+++ b/doc/neps/nep-0031-uarray.rst
@@ -359,7 +359,7 @@ NEP 18 notes that this may require maintenance of two separate APIs. However,
 this burden may be lessened by, for example, parametrizing all tests over
 ``numpy.overridable`` separately via a fixture. This also has the side-effect
 of thoroughly testing it, unlike ``__array_function__``. We also feel that it
-provides an oppurtunity to separate the NumPy API contract properly from the
+provides an opportunity to separate the NumPy API contract properly from the
 implementation.
 
 Benefits to end-users and mixing backends
diff --git a/doc/neps/nep-0035-array-creation-dispatch-with-array-function.rst b/doc/neps/nep-0035-array-creation-dispatch-with-array-function.rst
index 64d11a6f6..f6a77f754 100644
--- a/doc/neps/nep-0035-array-creation-dispatch-with-array-function.rst
+++ b/doc/neps/nep-0035-array-creation-dispatch-with-array-function.rst
@@ -209,7 +209,7 @@ libraries, preventing those libraries from using such important functionality in
 that context.
 
 The purpose of this NEP is to address that shortcoming in a simple and
-straighforward way: introduce a new ``like=`` keyword argument, similar to how
+straightforward way: introduce a new ``like=`` keyword argument, similar to how
 the ``empty_like`` family of functions work. When array creation functions
 receive such an argument, they will trigger the ``__array_function__`` protocol,
 and call the downstream library's own array creation function implementation.
diff --git a/doc/neps/nep-0036-fair-play.rst b/doc/neps/nep-0036-fair-play.rst
index 906247fd3..2acdcc704 100644
--- a/doc/neps/nep-0036-fair-play.rst
+++ b/doc/neps/nep-0036-fair-play.rst
@@ -126,7 +126,7 @@ Fair play rules
    were designed to help external packages interact more easily with
    NumPy.  E.g., the latter allows objects from foreign libraries to
    pass through NumPy.  We actively encourage using any of
-   these "officialy sanctioned" mechanisms for overriding or
+   these "officially sanctioned" mechanisms for overriding or
    interacting with NumPy.
 
    If these mechanisms are deemed insufficient, please start a
diff --git a/doc/neps/nep-0038-SIMD-optimizations.rst b/doc/neps/nep-0038-SIMD-optimizations.rst
index 396ba1371..927228447 100644
--- a/doc/neps/nep-0038-SIMD-optimizations.rst
+++ b/doc/neps/nep-0038-SIMD-optimizations.rst
@@ -64,7 +64,7 @@ mechanism for NumPy. There are three stages to using the mechanism:
 - Infrastructure is provided in the code for abstract intrinsics. The ufunc
   machinery will be extended using sets of these abstract intrinsics, so that
   a single ufunc will be expressed as a set of loops, going from a minimal to
-  a maximal set of possibly availabe intrinsics.
+  a maximal set of possibly available intrinsics.
 - At compile time, compiler macros and CPU detection are used to turn the
   abstract intrinsics into concrete intrinsic calls. Any intrinsics not
   available on the platform, either because the CPU does not support them
@@ -183,7 +183,7 @@ yet supported as a universal intrinsic, then:
 1. It should be added as a universal intrinsic for all platforms
 2. If it does not have an equivalent instruction on other platforms (e.g.
    ``_mm512_mask_i32gather_ps`` in ``AVX512``), then no universal intrinsic
-   should be added and a platform-specific ``ufunc`` or a short helper fuction
+   should be added and a platform-specific ``ufunc`` or a short helper function
    should be written instead. If such a helper function is used, it must be
    wrapped with the feature macros, and a reasonable non-intrinsic fallback to
    be used by default.
@@ -289,7 +289,7 @@ implementing and maintaining that platform's loop code.
 Discussion
 ----------
 
-Most of the discussion took place on the PR `gh-15228`_ to accecpt this NEP.
+Most of the discussion took place on the PR `gh-15228`_ to accept this NEP.
 Discussion on the mailing list mentioned `VOLK`_ which was added to
 the section on related work. The question of maintainability also was raised
 both on the mailing list and in `gh-15228`_ and resolved as follows:
diff --git a/doc/neps/nep-0040-legacy-datatype-impl.rst b/doc/neps/nep-0040-legacy-datatype-impl.rst
index 178fb590f..a6e74d7a0 100644
--- a/doc/neps/nep-0040-legacy-datatype-impl.rst
+++ b/doc/neps/nep-0040-legacy-datatype-impl.rst
@@ -82,7 +82,7 @@ Thus we have data types (mainly strings) with the properties that:
 2. Array coercion should be able to discover the exact dtype, such as for
    ``np.array(["str1", 12.34], dtype="S")`` where NumPy discovers the
    resulting dtype as ``"S5"``.
-   (If the dtype argument is ommitted the behaviour is currently ill defined [gh-15327]_.)
+   (If the dtype argument is omitted the behaviour is currently ill defined [gh-15327]_.)
    A form similar to ``dtype="S"`` is ``dtype="datetime64"`` which can
    discover the unit: ``np.array(["2017-02"], dtype="datetime64")``.
 
@@ -197,7 +197,7 @@ Currently ``np.dtype`` is a Python class with its instances being the
 To set the actual behaviour of these instances, a prototype instance is stored
 globally and looked up based on the ``dtype.typenum``. The singleton is used
 where possible. Where required it is copied and modified, for instance to change
-endianess.
+endianness.
 
 Parametric datatypes (strings, void, datetime, and timedelta) must store
 additional information such as string lengths, fields, or datetime units --
diff --git a/doc/neps/nep-0041-improved-dtype-support.rst b/doc/neps/nep-0041-improved-dtype-support.rst
index 0e0a5ac53..2fb907073 100644
--- a/doc/neps/nep-0041-improved-dtype-support.rst
+++ b/doc/neps/nep-0041-improved-dtype-support.rst
@@ -284,7 +284,7 @@ in general, it is not safe::
     >>> np.can_cast(np.float64, np.dtype[mp.mpf](dps=4), casting="safe")
     False
 
-since a float64 has a higer precision than the ``mpf`` datatype with
+since a float64 has a higher precision than the ``mpf`` datatype with
 ``dps=4``.
 
 Alternatively, we can say that::
@@ -765,7 +765,7 @@ Discussion
 See :ref:`NEP 40 <NEP40>`
 for a list of previous meetings and discussions.
 
-Additional discussion around this specific NEP has occured on both
+Additional discussion around this specific NEP has occurred on both
 the mailing list and the pull request:
 
 * `Mailing list discussion <https://mail.python.org/pipermail/numpy-discussion/2020-March/080481.html>`_
diff --git a/doc/neps/nep-0042-new-dtypes.rst b/doc/neps/nep-0042-new-dtypes.rst
index bb85f1d10..c29172a28 100644
--- a/doc/neps/nep-0042-new-dtypes.rst
+++ b/doc/neps/nep-0042-new-dtypes.rst
@@ -214,7 +214,7 @@ which describes the casting from one DType to another. In
 :ref:`NEP 43 <NEP43>` this ``CastingImpl`` object is used unchanged to
 support universal functions.
 Note that the name ``CastingImpl`` here will be generically called
-``ArrayMethod`` to accomodate both casting and universal functions.
+``ArrayMethod`` to accommodate both casting and universal functions.
 
 
 ******************************************************************************
diff --git a/doc/neps/nep-0043-extensible-ufuncs.rst b/doc/neps/nep-0043-extensible-ufuncs.rst
index 45cdc8ee4..3312eb12c 100644
--- a/doc/neps/nep-0043-extensible-ufuncs.rst
+++ b/doc/neps/nep-0043-extensible-ufuncs.rst
@@ -571,7 +571,7 @@ This stores all of the constant information that is part of the ``Context``,
 such as:
 
 * the ``DTypes``
-* the number of input and ouput arguments
+* the number of input and output arguments
 * the ufunc signature (specific to generalized ufuncs, compare :ref:`NEP20`).
 
 Fortunately, most users and even ufunc implementers will not have to worry
@@ -1233,7 +1233,7 @@ are the best solution:
    logic fails or is incorrect for a newly-added loop, the loop can add a
    new promoter to refine the logic.
 
-The option of having each loop verify that no upcast occured is probably
+The option of having each loop verify that no upcast occurred is probably
 the best alternative, but does not include the ability to dynamically
 adding new loops.
 
diff --git a/doc/neps/nep-0049.rst b/doc/neps/nep-0049.rst
index 6a17f33b5..51a3f11b1 100644
--- a/doc/neps/nep-0049.rst
+++ b/doc/neps/nep-0049.rst
@@ -43,10 +43,10 @@ override ``malloc``.
 
 The long CPython discussion of `BPO 18835`_  began with discussing the need for
 ``PyMem_Alloc32`` and ``PyMem_Alloc64``.  The early conclusion was that the
-cost (of wasted padding) vs. the benifit of aligned memory is best left to the
+cost (of wasted padding) vs. the benefit of aligned memory is best left to the
 user, but then evolves into a discussion of various proposals to deal with
 memory allocations, including `PEP 445`_ `memory interfaces`_ to
-``PyTraceMalloc_Track`` which apparently was explictly added for NumPy.
+``PyTraceMalloc_Track`` which apparently was explicitly added for NumPy.
 
 Allowing users to implement different strategies via the NumPy C-API will
 enable exploration of this rich area of possible optimizations. The intention
diff --git a/setup.cfg b/setup.cfg
index 2dbdf0566..f36b4b624 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,5 +1,5 @@
 [codespell]
-skip = *-changelog.rst,*-notes.rst,neps,f2c_blas.c,f2c_c_lapack.c,f2c_d_lapack.c,f2c_s_lapack.c,f2c_z_lapack.c
+skip = *-changelog.rst,*-notes.rst,f2c_blas.c,f2c_c_lapack.c,f2c_d_lapack.c,f2c_s_lapack.c,f2c_z_lapack.c
 
 # See the docstring in versioneer.py for instructions. Note that you must
 # re-run 'versioneer.py setup' after changing this section, and commit the