Merge pull request numpy#26881 from DimitriPapadopoulos/codespell

DOC, MAINT: fix typos found by codespell

Author: charris

doc/Makefile

@@ -17,7 +17,7 @@ PAPER         ?=
 DOXYGEN       ?= doxygen
 # For merging a documentation archive into a git checkout of numpy/doc
 # Turn a tag like v1.18.0 into 1.18
-# Use sed -n -e 's/patttern/match/p' to return a blank value if no match
+# Use sed -n -e 's/pattern/match/p' to return a blank value if no match
 TAG ?= $(shell git describe --tag | sed -n -e's,v\([1-9]\.[0-9]*\)\.[0-9].*,\1,p')
 
 FILES=

doc/neps/nep-0055-string_dtype.rst

@@ -990,7 +990,7 @@ in the array buffer as a short string.
 
 No matter where it is stored, once a string is initialized it is marked with the
 ``NPY_STRING_INITIALIZED`` flag. This lets us clearly distinguish between an
-unitialized empty string and a string that has been mutated into the empty
+uninitialized empty string and a string that has been mutated into the empty
 string.
 
 The size of the allocation is stored in the arena to allow reuse of the arena

doc/neps/nep-0056-array-api-main-namespace.rst

@@ -302,7 +302,7 @@ three types of behavior rather than two - ``copy=None`` means "copy if needed".
 an exception because they use* ``copy=False`` *explicitly in their copy but a
 copy was previously made anyway, they have to inspect their code and determine
 whether the intent of the code was the old or the new semantics (both seem
-rougly equally likely), and adapt the code as appropriate. We expect most cases
+roughly equally likely), and adapt the code as appropriate. We expect most cases
 to be* ``np.array(..., copy=False)``, *because until a few years ago that had
 lower overhead than* ``np.asarray(...)``. *This was solved though, and*
 ``np.asarray(...)`` *is idiomatic NumPy usage.*

doc/source/numpy_2_0_migration_guide.rst

@@ -213,7 +213,7 @@ have been added for setting the real or imaginary part.
 The underlying type remains a struct under C++ (all of the above still remains
 valid).
 
-This has implications for Cython. It is recommened to always use the native
+This has implications for Cython. It is recommended to always use the native
 typedefs ``cfloat_t``, ``cdouble_t``, ``clongdouble_t`` rather than the NumPy
 types ``npy_cfloat``, etc, unless you have to interface with C code written
 using the NumPy types. You can still write cython code using the ``c.real`` and

doc/source/reference/array_api.rst

@@ -18,7 +18,7 @@ upgraded to given NumPy's
 For usage guidelines for downstream libraries and end users who want to write
 code that will work with both NumPy and other array libraries, we refer to the
 documentation of the array API standard itself and to code and
-developer-focused documention in SciPy and scikit-learn.
+developer-focused documentation in SciPy and scikit-learn.
 
 Note that in order to use standard-complaint code with older NumPy versions
 (< 2.0), the `array-api-compat

doc/source/reference/c-api/array.rst

@@ -823,7 +823,7 @@ cannot not be accessed directly.
 
 .. c:function:: PyArray_ArrayDescr *PyDataType_SUBARRAY(PyArray_Descr *descr)
 
-    Information about a subarray dtype eqivalent to the Python `np.dtype.base`
+    Information about a subarray dtype equivalent to the Python `np.dtype.base`
     and `np.dtype.shape`.
 
     If this is non- ``NULL``, then this data-type descriptor is a
@@ -3975,7 +3975,7 @@ the C-API is needed then some additional steps must be taken.
     behavior as NumPy 1.x.
 
     .. note::
-        Windows never had shared visbility although you can use this macro
+        Windows never had shared visibility although you can use this macro
         to achieve it.  We generally discourage sharing beyond shared boundary
         lines since importing the array API includes NumPy version checks.
 

doc/source/release/2.0.0-notes.rst

@@ -653,7 +653,7 @@ The ``metadata`` field is kept, but the macro version should also be preferred.
 
 Descriptor ``elsize`` and ``alignment`` access
 ----------------------------------------------
-Unless compiling only with NumPy 2 support, the ``elsize`` and ``aligment``
+Unless compiling only with NumPy 2 support, the ``elsize`` and ``alignment``
 fields must now be accessed via ``PyDataType_ELSIZE``,
 ``PyDataType_SET_ELSIZE``, and ``PyDataType_ALIGNMENT``.
 In cases where the descriptor is attached to an array, we advise

numpy/_core/include/numpy/ndarraytypes.h

@@ -1302,7 +1302,7 @@ typedef struct {
         PyArrayIterObject    *iters[64];
 #elif defined(__cplusplus)
         /*
-         * C++ doesn't stricly support flexible members and gives compilers
+         * C++ doesn't strictly support flexible members and gives compilers
          * warnings (pedantic only), so we lie.  We can't make it 64 because
          * then Cython is unhappy (larger struct at runtime is OK smaller not).
          */

numpy/_core/include/numpy/npy_2_compat.h

@@ -53,7 +53,7 @@
 #if NPY_ABI_VERSION < 0x02000000
   /*
    * Define 2.0 feature version as it is needed below to decide whether we
-   * compile for both 1.x and 2.x (defining it gaurantees 1.x only).
+   * compile for both 1.x and 2.x (defining it guarantees 1.x only).
    */
   #define NPY_2_0_API_VERSION 0x00000012
   /*

numpy/_core/src/_simd/_simd_vector.inc

@@ -92,7 +92,7 @@ static PyTypeObject PySIMDVectorType = {
  * miss-align load variable of 256/512-bit vector from non-aligned
  * 256/512-bit stack pointer.
  *
- * check the following links for more clearification:
+ * check the following links for more clarification:
  * https://github.com/numpy/numpy/pull/18330#issuecomment-821539919
  * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
  */