Merge pull request numpy#19920 from DimitriPapadopoulos/codespell-neps

DOC: Fix typos in NEPs, found by codespell

Author: seberg

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.
 

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::

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

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>

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

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.

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

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:

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 --

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>`_