Merge pull request #19911 from DimitriPapadopoulos/codespell

DOC: Typos found by codespell

25 files changed, 47 insertions, 47 deletions

diff --git a/doc/source/dev/development_advanced_debugging.rst b/doc/source/dev/development_advanced_debugging.rst
index fa4014fdb..18a7f6ae9 100644
--- a/doc/source/dev/development_advanced_debugging.rst
+++ b/doc/source/dev/development_advanced_debugging.rst
@@ -3,8 +3,8 @@ Advanced debugging tools
 ========================
 
 If you reached here, you want to dive into, or use, more advanced tooling.
-This is usually not necessary for first time contributers and most
-day-to-day developement.
+This is usually not necessary for first time contributors and most
+day-to-day development.
 These are used more rarely, for example close to a new NumPy release,
 or when a large or particular complex change was made.
 
@@ -25,7 +25,7 @@ narrow down.
 We do not expect any of these tools to be run by most contributors.
 However, you can ensure that we can track down such issues more easily easier:
 
-* Tests should cover all code paths, incluing error paths.
+* Tests should cover all code paths, including error paths.
 * Try to write short and simple tests. If you have a very complicated test
   consider creating an additional simpler test as well.
   This can be helpful, because often it is only easy to find which test
@@ -112,7 +112,7 @@ where ``PYTHONMALLOC=malloc`` is necessary to avoid false positives from python
 itself.
 Depending on the system and valgrind version, you may see more false positives.
 ``valgrind`` supports "suppressions" to ignore some of these, and Python does
-have a supression file (and even a compile time option) which may help if you
+have a suppression file (and even a compile time option) which may help if you
 find it necessary.
 
 Valgrind helps:
diff --git a/doc/source/dev/development_environment.rst b/doc/source/dev/development_environment.rst
index 665198c69..37cf6f7af 100644
--- a/doc/source/dev/development_environment.rst
+++ b/doc/source/dev/development_environment.rst
@@ -122,7 +122,7 @@ source tree is to use::
 
 
 NumPy uses a series of tests to probe the compiler and libc libraries for
-funtions. The results are stored in ``_numpyconfig.h`` and ``config.h`` files
+functions. The results are stored in ``_numpyconfig.h`` and ``config.h`` files
 using ``HAVE_XXX`` definitions. These tests are run during the ``build_src``
 phase of the ``_multiarray_umath`` module in the ``generate_config_h`` and
 ``generate_numpyconfig_h`` functions. Since the output of these calls includes
diff --git a/doc/source/dev/howto-docs.rst b/doc/source/dev/howto-docs.rst
index cc17a1feb..93fec509c 100644
--- a/doc/source/dev/howto-docs.rst
+++ b/doc/source/dev/howto-docs.rst
@@ -60,7 +60,7 @@ category, but other rewordings -- even for grammar -- require a judgment call,
 which raises the bar. Test the waters by first presenting the fix as an issue.
 
 Some functions/objects like numpy.ndarray.transpose, numpy.array etc. defined in
-C-extension modules have their docstrings defined seperately in `_add_newdocs.py
+C-extension modules have their docstrings defined separately in `_add_newdocs.py
 <https://github.com/numpy/numpy/blob/main/numpy/core/_add_newdocs.py>`__
 
 **********************
@@ -72,7 +72,7 @@ Your frustrations using our documents are our best guide to what needs fixing.
 If you write a missing doc you join the front line of open source, but it's
 a meaningful contribution just to let us know what's missing. If you want to
 compose a doc, run your thoughts by the `mailing list
-<https://mail.python.org/mailman/listinfo/numpy-discussion>`__ for futher
+<https://mail.python.org/mailman/listinfo/numpy-discussion>`__ for further
 ideas and feedback. If you want to alert us to a gap,
 `open an issue <https://github.com/numpy/numpy/issues>`__. See
 `this issue <https://github.com/numpy/numpy/issues/15760>`__ for an example.
diff --git a/doc/source/reference/arrays.scalars.rst b/doc/source/reference/arrays.scalars.rst
index abef66692..ccab0101e 100644
--- a/doc/source/reference/arrays.scalars.rst
+++ b/doc/source/reference/arrays.scalars.rst
@@ -399,7 +399,7 @@ are also provided.
                complex256
 
    Alias for `numpy.clongdouble`, named after its size in bits.
-   The existance of these aliases depends on the platform.
+   The existence of these aliases depends on the platform.
 
 Other aliases
 ~~~~~~~~~~~~~
diff --git a/doc/source/reference/c-api/iterator.rst b/doc/source/reference/c-api/iterator.rst
index 2208cdd2f..83644d8b2 100644
--- a/doc/source/reference/c-api/iterator.rst
+++ b/doc/source/reference/c-api/iterator.rst
@@ -1230,7 +1230,7 @@ Functions For Iteration
 .. c:function:: 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 :c:data:`NPY_ITER_C_INDEX` or :c:data:`NPY_ITER_F_INDEX`
     were specified during construction.
 
diff --git a/doc/source/reference/c-api/types-and-structures.rst b/doc/source/reference/c-api/types-and-structures.rst
index 39a17cc72..36293ce99 100644
--- a/doc/source/reference/c-api/types-and-structures.rst
+++ b/doc/source/reference/c-api/types-and-structures.rst
@@ -94,7 +94,7 @@ PyArray_Type and PyArrayObject
           PyArray_Descr *descr;
           int flags;
           PyObject *weakreflist;
-          /* version dependend private members */
+          /* version dependent private members */
       } PyArrayObject;
 
    .. c:macro:: PyObject_HEAD
@@ -178,7 +178,7 @@ PyArray_Type and PyArrayObject
 
    .. note::
 
-      Further members are considered private and version dependend. If the size
+      Further members are considered private and version dependent. If the size
       of the struct is important for your code, special care must be taken.
       A possible use-case when this is relevant is subclassing in C.
       If your code relies on ``sizeof(PyArrayObject)`` to be constant,
diff --git a/doc/source/reference/random/bit_generators/index.rst b/doc/source/reference/random/bit_generators/index.rst
index c5c349806..211f0d60e 100644
--- a/doc/source/reference/random/bit_generators/index.rst
+++ b/doc/source/reference/random/bit_generators/index.rst
@@ -4,7 +4,7 @@ Bit Generators
 --------------
 
 The random values produced by :class:`~Generator`
-orignate in a BitGenerator.  The BitGenerators do not directly provide
+originate in a BitGenerator.  The BitGenerators do not directly provide
 random numbers and only contains methods used for seeding, getting or
 setting the state, jumping or advancing the state, and for accessing
 low-level wrappers for consumption by code that can efficiently
diff --git a/doc/source/reference/routines.ma.rst b/doc/source/reference/routines.ma.rst
index d961cbf02..2db325293 100644
--- a/doc/source/reference/routines.ma.rst
+++ b/doc/source/reference/routines.ma.rst
@@ -287,11 +287,11 @@ Filling a masked array
 
 _____
 
-Masked arrays arithmetics
-=========================
+Masked arrays arithmetic
+========================
 
-Arithmetics
-~~~~~~~~~~~
+Arithmetic
+~~~~~~~~~~
 .. autosummary::
    :toctree: generated/
 
diff --git a/doc/source/reference/routines.polynomials.rst b/doc/source/reference/routines.polynomials.rst
index ecfb012f0..4aea963c0 100644
--- a/doc/source/reference/routines.polynomials.rst
+++ b/doc/source/reference/routines.polynomials.rst
@@ -22,7 +22,7 @@ Therefore :mod:`numpy.polynomial` is recommended for new coding.
    the polynomial functions prefixed with *poly* accessible from the `numpy`
    namespace (e.g. `numpy.polyadd`, `numpy.polyval`, `numpy.polyfit`, etc.).
 
-   The term *polynomial package* refers to the new API definied in 
+   The term *polynomial package* refers to the new API defined in 
    `numpy.polynomial`, which includes the convenience classes for the
    different kinds of polynomials (`numpy.polynomial.Polynomial`,
    `numpy.polynomial.Chebyshev`, etc.).
@@ -110,7 +110,7 @@ See the documentation for the
 `convenience classes <routines.polynomials.classes>`_ for further details on
 the ``domain`` and ``window`` attributes.
 
-Another major difference bewteen the legacy polynomial module and the
+Another major difference between the legacy polynomial module and the
 polynomial package is polynomial fitting. In the old module, fitting was
 done via the `~numpy.polyfit` function. In the polynomial package, the
 `~numpy.polynomial.polynomial.Polynomial.fit` class method is preferred. For
diff --git a/doc/source/reference/simd/simd-optimizations.rst b/doc/source/reference/simd/simd-optimizations.rst
index 956824321..9de6d1734 100644
--- a/doc/source/reference/simd/simd-optimizations.rst
+++ b/doc/source/reference/simd/simd-optimizations.rst
@@ -14,7 +14,7 @@ written only once. There are three layers:
   written using the maximum set of intrinsics possible.
 - At *compile* time, a distutils command is used to define the minimum and
   maximum features to support, based on user choice and compiler support. The
-  appropriate macros are overlayed with the platform / architecture intrinsics,
+  appropriate macros are overlaid with the platform / architecture intrinsics,
   and the three loops are compiled.
 - At *runtime import*, the CPU is probed for the set of supported intrinsic
   features. A mechanism is used to grab the pointer to the most appropriate
@@ -89,7 +89,7 @@ NOTES
 ~~~~~~~~~~~~~
 - CPU features and other options are case-insensitive.
 
-- The order of the requsted optimizations doesn't matter.
+- The order of the requested optimizations doesn't matter.
 
 - Either commas or spaces can be used as a separator, e.g. ``--cpu-dispatch``\ =
   "avx2 avx512f" or ``--cpu-dispatch``\ = "avx2, avx512f" both work, but the
@@ -113,7 +113,7 @@ NOTES
   compiler native flag ``-march=native`` or ``-xHost`` or ``QxHost`` is
   enabled through environment variable ``CFLAGS``
 
-- The validation process for the requsted optimizations when it comes to
+- The validation process for the requested optimizations when it comes to
   ``--cpu-baseline`` isn't strict. For example, if the user requested
   ``AVX2`` but the compiler doesn't support it then we just skip it and return
   the maximum optimization that the compiler can handle depending on the
@@ -379,15 +379,15 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       #include "numpy/utils.h" // NPY_CAT, NPY_TOSTR
 
       #ifndef NPY__CPU_TARGET_CURRENT
-        // wrapping the dispatch-able source only happens to the addtional optimizations
-        // but if the keyword 'baseline' provided within the configuration statments,
+        // wrapping the dispatch-able source only happens to the additional optimizations
+        // but if the keyword 'baseline' provided within the configuration statements,
         // the infrastructure will add extra compiling for the dispatch-able source by
         // passing it as-is to the compiler without any changes.
         #define CURRENT_TARGET(X) X
         #define NPY__CPU_TARGET_CURRENT baseline // for printing only
       #else
         // since we reach to this point, that's mean we're dealing with
-          // the addtional optimizations, so it could be SSE42 or AVX512F
+          // the additional optimizations, so it could be SSE42 or AVX512F
         #define CURRENT_TARGET(X) NPY_CAT(NPY_CAT(X, _), NPY__CPU_TARGET_CURRENT)
       #endif
       // Macro 'CURRENT_TARGET' adding the current target as suffux to the exported symbols,
@@ -418,7 +418,7 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       #undef NPY__CPU_DISPATCH_BASELINE_CALL
       #undef NPY__CPU_DISPATCH_CALL
       // nothing strange here, just a normal preprocessor callback
-      // enabled only if 'baseline' spesfied withiin the configration statments
+      // enabled only if 'baseline' specified within the configuration statements
       #define NPY__CPU_DISPATCH_BASELINE_CALL(CB, ...) \
         NPY__CPU_DISPATCH_EXPAND_(CB(__VA_ARGS__))
       // 'NPY__CPU_DISPATCH_CALL' is an abstract macro is used for dispatching
@@ -427,7 +427,7 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       // @param CHK, Expected a macro that can be used to detect CPU features
       // in runtime, which takes a CPU feature name without string quotes and
       // returns the testing result in a shape of boolean value.
-      // NumPy already has macro called "NPY_CPU_HAVE", which fit this requirment.
+      // NumPy already has macro called "NPY_CPU_HAVE", which fits this requirement.
       //
       // @param CB, a callback macro that expected to be called multiple times depending
       // on the required optimizations, the callback should receive the following arguments:
diff --git a/doc/source/reference/ufuncs.rst b/doc/source/reference/ufuncs.rst
index b832dad04..6ace5b233 100644
--- a/doc/source/reference/ufuncs.rst
+++ b/doc/source/reference/ufuncs.rst
@@ -185,7 +185,7 @@ attribute of the ufunc.  (This list may be missing DTypes not defined
 by NumPy.)
 
 The ``signature`` only specifies the DType class/type.  For example, it
-can specifiy that the operation should be ``datetime64`` or ``float64``
+can specify that the operation should be ``datetime64`` or ``float64``
 operation.  It does not specify the ``datetime64`` time-unit or the
 ``float64`` byte-order.
 
diff --git a/doc/source/release/1.14.0-notes.rst b/doc/source/release/1.14.0-notes.rst
index 8ee876fd3..346b5af99 100644
--- a/doc/source/release/1.14.0-notes.rst
+++ b/doc/source/release/1.14.0-notes.rst
@@ -332,7 +332,7 @@ eliminating their use internally and two new C-API functions,
 * ``PyArray_SetWritebackIfCopyBase``
 * ``PyArray_ResolveWritebackIfCopy``,
 
-have been added together with a complimentary flag,
+have been added together with a complementary flag,
 ``NPY_ARRAY_WRITEBACKIFCOPY``. Using the new functionality also requires that
 some flags be changed when new arrays are created, to wit:
 ``NPY_ARRAY_INOUT_ARRAY`` should be replaced by ``NPY_ARRAY_INOUT_ARRAY2`` and
diff --git a/doc/source/release/1.15.0-notes.rst b/doc/source/release/1.15.0-notes.rst
index 7235ca915..2d9d068e5 100644
--- a/doc/source/release/1.15.0-notes.rst
+++ b/doc/source/release/1.15.0-notes.rst
@@ -326,8 +326,8 @@ passed explicitly, and are not yet computed automatically.
 No longer does an IQR of 0 result in ``n_bins=1``, rather the number of bins
 chosen is related to the data size in this situation.
 
-The edges retuned by `histogram`` and ``histogramdd`` now match the data float type
------------------------------------------------------------------------------------
+The edges returned by `histogram`` and ``histogramdd`` now match the data float type
+------------------------------------------------------------------------------------
 When passed ``np.float16``, ``np.float32``, or ``np.longdouble`` data, the
 returned edges are now of the same dtype. Previously, ``histogram`` would only
 return the same type if explicit bins were given, and ``histogram`` would
diff --git a/doc/source/release/1.16.0-notes.rst b/doc/source/release/1.16.0-notes.rst
index 17d24160a..122f20eba 100644
--- a/doc/source/release/1.16.0-notes.rst
+++ b/doc/source/release/1.16.0-notes.rst
@@ -119,7 +119,7 @@ NaT comparisons
 Consistent with the behavior of NaN, all comparisons other than inequality
 checks with datetime64 or timedelta64 NaT ("not-a-time") values now always
 return ``False``, and inequality checks with NaT now always return ``True``.
-This includes comparisons beteween NaT values. For compatibility with the
+This includes comparisons between NaT values. For compatibility with the
 old behavior, use ``np.isnat`` to explicitly check for NaT or convert
 datetime64/timedelta64 arrays with ``.astype(np.int64)`` before making
 comparisons.
@@ -365,7 +365,7 @@ Alpine Linux (and other musl c library distros) support
 We now default to use `fenv.h` for floating point status error reporting.
 Previously we had a broken default that sometimes would not report underflow,
 overflow, and invalid floating point operations. Now we can support non-glibc
-distrubutions like Alpine Linux as long as they ship `fenv.h`.
+distributions like Alpine Linux as long as they ship `fenv.h`.
 
 Speedup ``np.block`` for large arrays
 -------------------------------------
diff --git a/doc/source/release/1.19.0-notes.rst b/doc/source/release/1.19.0-notes.rst
index 8f5c2c0ce..410890697 100644
--- a/doc/source/release/1.19.0-notes.rst
+++ b/doc/source/release/1.19.0-notes.rst
@@ -402,7 +402,7 @@ Ability to disable madvise hugepages
 ------------------------------------
 On Linux NumPy has previously added support for madavise hugepages which can
 improve performance for very large arrays.  Unfortunately, on older Kernel
-versions this led to peformance regressions, thus by default the support has
+versions this led to performance regressions, thus by default the support has
 been disabled on kernels before version 4.6. To override the default, you can
 use the environment variable::
 
diff --git a/doc/source/release/1.20.0-notes.rst b/doc/source/release/1.20.0-notes.rst
index b8b7a0c79..494e4f19e 100644
--- a/doc/source/release/1.20.0-notes.rst
+++ b/doc/source/release/1.20.0-notes.rst
@@ -842,7 +842,7 @@ The compiler command selection for Fortran Portland Group Compiler is changed
 in `numpy.distutils.fcompiler`.  This only affects the linking command.  This
 forces the use of the executable provided by the command line option (if
 provided) instead of the pgfortran executable.  If no executable is provided to
-the command line option it defaults to the pgf90 executable, wich is an alias
+the command line option it defaults to the pgf90 executable, which is an alias
 for pgfortran according to the PGI documentation.
 
 (`gh-16730 <https://github.com/numpy/numpy/pull/16730>`__)
diff --git a/doc/source/release/1.21.0-notes.rst b/doc/source/release/1.21.0-notes.rst
index 270cc32de..88a4503de 100644
--- a/doc/source/release/1.21.0-notes.rst
+++ b/doc/source/release/1.21.0-notes.rst
@@ -522,7 +522,7 @@ either of these distributions are produced.
 Placeholder annotations have been improved
 ------------------------------------------
 All placeholder annotations, that were previously annotated as ``typing.Any``,
-have been improved. Where appropiate they have been replaced with explicit
+have been improved. Where appropriate they have been replaced with explicit
 function definitions, classes or other miscellaneous objects.
 
 (`gh-18934 <https://github.com/numpy/numpy/pull/18934>`__)
diff --git a/doc/source/release/1.8.0-notes.rst b/doc/source/release/1.8.0-notes.rst
index 80c39f8bc..65a471b92 100644
--- a/doc/source/release/1.8.0-notes.rst
+++ b/doc/source/release/1.8.0-notes.rst
@@ -33,7 +33,7 @@ Future Changes
 
 
 The Datetime64 type remains experimental in this release. In 1.9 there will
-probably be some changes to make it more useable.
+probably be some changes to make it more usable.
 
 The diagonal method currently returns a new array and raises a
 FutureWarning. In 1.9 it will return a readonly view.
@@ -315,8 +315,8 @@ If used with the `overwrite_input` option the array will now only be partially
 sorted instead of fully sorted.
 
 
-Overrideable operand flags in ufunc C-API
------------------------------------------
+Overridable operand flags in ufunc C-API
+----------------------------------------
 When creating a ufunc, the default ufunc operand flags can be overridden
 via the new op_flags attribute of the ufunc object. For example, to set
 the operand flag for the first input to read/write:
diff --git a/doc/source/release/1.9.0-notes.rst b/doc/source/release/1.9.0-notes.rst
index 7ea29e354..a19a05cb7 100644
--- a/doc/source/release/1.9.0-notes.rst
+++ b/doc/source/release/1.9.0-notes.rst
@@ -389,7 +389,7 @@ uses a per-state lock instead of the GIL.
 MaskedArray support for more complicated base classes
 -----------------------------------------------------
 Built-in assumptions that the baseclass behaved like a plain array are being
-removed. In particalur, ``repr`` and ``str`` should now work more reliably.
+removed. In particular, ``repr`` and ``str`` should now work more reliably.
 
 
 C-API
diff --git a/doc/source/user/basics.creation.rst b/doc/source/user/basics.creation.rst
index 5fb4f66f6..84ff1c30e 100644
--- a/doc/source/user/basics.creation.rst
+++ b/doc/source/user/basics.creation.rst
@@ -115,7 +115,7 @@ examples are shown::
 Note: best practice for :func:`numpy.arange` is to use integer start, end, and
 step values. There are some subtleties regarding ``dtype``. In the second
 example, the ``dtype`` is defined. In the third example, the array is
-``dtype=float`` to accomodate the step size of ``0.1``. Due to roundoff error,
+``dtype=float`` to accommodate the step size of ``0.1``. Due to roundoff error,
 the ``stop`` value is sometimes included. 
 
 :func:`numpy.linspace` will create arrays with a specified number of elements, and
diff --git a/doc/source/user/c-info.how-to-extend.rst b/doc/source/user/c-info.how-to-extend.rst
index ebb4b7518..96727a177 100644
--- a/doc/source/user/c-info.how-to-extend.rst
+++ b/doc/source/user/c-info.how-to-extend.rst
@@ -433,7 +433,7 @@ writeable). The syntax is
 
         The requirements flag allows specification of what kind of
         array is acceptable. If the object passed in does not satisfy
-        this requirements then a copy is made so that thre returned
+        this requirements then a copy is made so that the returned
         object will satisfy the requirements. these ndarray can use a
         very generic pointer to memory.  This flag allows specification
         of the desired properties of the returned array object. All
diff --git a/doc/source/user/c-info.python-as-glue.rst b/doc/source/user/c-info.python-as-glue.rst
index 8643d0dd1..2798aa08a 100644
--- a/doc/source/user/c-info.python-as-glue.rst
+++ b/doc/source/user/c-info.python-as-glue.rst
@@ -1115,7 +1115,7 @@ SWIG
 Simplified Wrapper and Interface Generator (SWIG) is an old and fairly
 stable method for wrapping C/C++-libraries to a large variety of other
 languages. It does not specifically understand NumPy arrays but can be
-made useable with NumPy through the use of typemaps. There are some
+made usable with NumPy through the use of typemaps. There are some
 sample typemaps in the numpy/tools/swig directory under numpy.i together
 with an example module that makes use of them. SWIG excels at wrapping
 large C/C++ libraries because it can (almost) parse their headers and
diff --git a/doc/source/user/how-to-how-to.rst b/doc/source/user/how-to-how-to.rst
index 13d2b405f..cdf1ad5c3 100644
--- a/doc/source/user/how-to-how-to.rst
+++ b/doc/source/user/how-to-how-to.rst
@@ -102,7 +102,7 @@ knowledge).
 
 We distinguish both tutorials and how-tos from `Explanations`, which are
 deep dives intended to give understanding rather than immediate assistance,
-and `References`, which give complete, autoritative data on some concrete
+and `References`, which give complete, authoritative data on some concrete
 part of NumPy (like its API) but aren't obligated to paint a broader picture.
 
 For more on tutorials, see :doc:`content/tutorial-style-guide`
diff --git a/doc/source/user/misc.rst b/doc/source/user/misc.rst
index f0a7f5e4c..316473151 100644
--- a/doc/source/user/misc.rst
+++ b/doc/source/user/misc.rst
@@ -143,7 +143,7 @@ Only a survey of the choices. Little detail on how each works.
  - Plusses:
 
    - part of Python standard library
-   - good for interfacing to existing sharable libraries, particularly
+   - good for interfacing to existing shareable libraries, particularly
      Windows DLLs
    - avoids API/reference counting issues
    - good numpy support: arrays have all these in their ctypes
diff --git a/doc/source/user/numpy-for-matlab-users.rst b/doc/source/user/numpy-for-matlab-users.rst
index ed0be82a0..21e23482a 100644
--- a/doc/source/user/numpy-for-matlab-users.rst
+++ b/doc/source/user/numpy-for-matlab-users.rst
@@ -313,11 +313,11 @@ Linear algebra equivalents
 
    * - ``a(:,find(v > 0.5))``
      - ``a[:,np.nonzero(v > 0.5)[0]]``
-     - extract the columms of ``a`` where vector v > 0.5
+     - extract the columns of ``a`` where vector v > 0.5
 
    * - ``a(:,find(v>0.5))``
      - ``a[:, v.T > 0.5]``
-     - extract the columms of ``a`` where column vector v > 0.5
+     - extract the columns of ``a`` where column vector v > 0.5
 
    * - ``a(a<0.5)=0``
      - ``a[a < 0.5]=0``
@@ -819,6 +819,6 @@ found in the `topical software page <https://scipy.org/topical-software.html>`__
 See
 `List of Python software: scripting
 <https://en.wikipedia.org/wiki/List_of_Python_software#Embedded_as_a_scripting_language>`_
-for a list of softwares that use Python as a scripting language
+for a list of software that use Python as a scripting language
 
 MATLAB® and SimuLink® are registered trademarks of The MathWorks, Inc.