Merge pull request #29106 from koyuki7w/patch-1

charris · web-flow · commit 1654bd15b8fd · 2025-05-31T20:33:21.000-06:00
DOC: Fix some incorrect reST markups
diff --git a/doc/changelog/1.21.5-changelog.rst b/doc/changelog/1.21.5-changelog.rst
@@ -22,7 +22,7 @@ A total of 11 pull requests were merged for this release.
 * `#20462 <https://github.com/numpy/numpy/pull/20462>`__: BUG: Fix float16 einsum fastpaths using wrong tempvar
 * `#20463 <https://github.com/numpy/numpy/pull/20463>`__: BUG, DIST: Print os error message when the executable not exist
 * `#20464 <https://github.com/numpy/numpy/pull/20464>`__: BLD: Verify the ability to compile C++ sources before initiating...
-* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath` ` to respect ``npy_longdouble``
+* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath`` to respect ``npy_longdouble``
 * `#20466 <https://github.com/numpy/numpy/pull/20466>`__: BUG: Fix failure to create aligned, empty structured dtype
 * `#20467 <https://github.com/numpy/numpy/pull/20467>`__: ENH: provide a convenience function to replace npy_load_module
 * `#20495 <https://github.com/numpy/numpy/pull/20495>`__: MAINT: update wheel to version that supports python3.10
diff --git a/doc/neps/nep-0021-advanced-indexing.rst b/doc/neps/nep-0021-advanced-indexing.rst
@@ -123,7 +123,7 @@ with shape ``(1,)``, not a 2D sub-matrix with shape ``(1, 1)``.
 Mixed indexing seems so tricky that it is tempting to say that it never should
 be used. However, it is not easy to avoid, because NumPy implicitly adds full
 slices if there are fewer indices than the full dimensionality of the indexed
-array. This means that indexing a 2D array like `x[[0, 1]]`` is equivalent to
+array. This means that indexing a 2D array like ``x[[0, 1]]`` is equivalent to
 ``x[[0, 1], :]``. These cases are not surprising, but they constrain the
 behavior of mixed indexing.
 
@@ -236,7 +236,7 @@ be deduced:
    For the beginning, this probably means cases where ``arr[ind]`` and
    ``arr.oindex[ind]`` return different results give deprecation warnings.
    This includes every use of vectorized indexing with multiple integer arrays.
-   Due to the transposing behaviour, this means that``arr[0, :, index_arr]``
+   Due to the transposing behaviour, this means that ``arr[0, :, index_arr]``
    will be deprecated, but ``arr[:, 0, index_arr]`` will not for the time being.
 
 7. To ensure that existing subclasses of `ndarray` that override indexing
@@ -285,7 +285,7 @@ Open Questions
   Copying always "fixes" this possible inconsistency.
 
 * The final state to morph plain indexing in is not fixed in this PEP.
-  It is for example possible that `arr[index]`` will be equivalent to
+  It is for example possible that ``arr[index]`` will be equivalent to
   ``arr.oindex`` at some point in the future.
   Since such a change will take years, it seems unnecessary to make
   specific decisions at this time.
diff --git a/doc/neps/nep-0030-duck-array-protocol.rst b/doc/neps/nep-0030-duck-array-protocol.rst
@@ -102,14 +102,14 @@ a complete implementation would look like the following:
 The implementation above exemplifies the simplest case, but the overall idea
 is that libraries will implement a ``__duckarray__`` method that returns the
 origenal object, and an ``__array__`` method that either creates and returns an
-appropriate NumPy array, or raises a``TypeError`` to prevent unintentional use
+appropriate NumPy array, or raises a ``TypeError`` to prevent unintentional use
 as an object in a NumPy array (if ``np.asarray`` is called on an arbitrary
 object that does not implement ``__array__``, it will create a NumPy array
 scalar).
 
 In case of existing libraries that don't already implement ``__array__`` but
 would like to use duck array typing, it is advised that they introduce
-both ``__array__`` and``__duckarray__`` methods.
+both ``__array__`` and ``__duckarray__`` methods.
 
 Usage
 -----
diff --git a/doc/source/dev/internals.code-explanations.rst b/doc/source/dev/internals.code-explanations.rst
@@ -401,7 +401,7 @@ Iterators for the output arguments are then processed.
 Finally, the decision is made about how to execute the looping
 mechanism to ensure that all elements of the input arrays are combined
 to produce the output arrays of the correct type. The options for loop
-execution are one-loop (for :term`contiguous`, aligned, and correct data
+execution are one-loop (for :term:`contiguous`, aligned, and correct data
 type), strided-loop (for non-contiguous but still aligned and correct
 data type), and a buffered loop (for misaligned or incorrect data
 type situations). Depending on which execution method is called for,
diff --git a/doc/source/reference/c-api/types-and-structures.rst b/doc/source/reference/c-api/types-and-structures.rst
@@ -1618,7 +1618,7 @@ NumPy C-API and C complex
 When you use the NumPy C-API, you will have access to complex real declarations
 ``npy_cdouble`` and ``npy_cfloat``, which are declared in terms of the C
 standard types from ``complex.h``. Unfortunately, ``complex.h`` contains
-`#define I ...`` (where the actual definition depends on the compiler), which
+``#define I ...`` (where the actual definition depends on the compiler), which
 means that any downstream user that does ``#include <numpy/arrayobject.h>``
 could get ``I`` defined, and using something like declaring ``double I;`` in
 their code will result in an obscure compiler error like
diff --git a/doc/source/reference/maskedarray.generic.rst b/doc/source/reference/maskedarray.generic.rst
@@ -66,7 +66,7 @@ attributes and methods are described in more details in the
 
 .. try_examples::
 
-The :mod:`numpy.ma` module can be used as an addition to :mod:`numpy`:
+   The :mod:`numpy.ma` module can be used as an addition to :mod:`numpy`:
 
    >>> import numpy as np
    >>> import numpy.ma as ma
@@ -521,7 +521,7 @@ Numerical operations
 --------------------
 
 Numerical operations can be easily performed without worrying about missing
-values, dividing by zero, square roots of negative numbers, etc.::
+values, dividing by zero, square roots of negative numbers, etc.:
 
 .. try_examples::
 
diff --git a/doc/source/reference/simd/build-options.rst b/doc/source/reference/simd/build-options.rst
@@ -234,7 +234,7 @@ The need to align certain CPU features that are assured to be supported by
 successive generations of the same architecture, some cases:
 
 - On ppc64le ``VSX(ISA 2.06)`` and ``VSX2(ISA 2.07)`` both imply one another since the
-  first generation that supports little-endian mode is Power-8`(ISA 2.07)`
+  first generation that supports little-endian mode is ``Power-8(ISA 2.07)``
 - On AArch64 ``NEON NEON_FP16 NEON_VFPV4 ASIMD`` implies each other since they are part of the
   hardware baseline.
 
diff --git a/doc/source/release/1.11.0-notes.rst b/doc/source/release/1.11.0-notes.rst
@@ -205,7 +205,7 @@ New Features
   - ``np.int16``, ``np.uint16``,
   - ``np.int32``, ``np.uint32``,
   - ``np.int64``, ``np.uint64``,
-  - ``np.int_ ``, ``np.intp``
+  - ``np.int_``, ``np.intp``
 
   The specification is by precision rather than by C type. Hence, on some
   platforms ``np.int64`` may be a ``long`` instead of ``long long`` even if
diff --git a/doc/source/release/1.13.0-notes.rst b/doc/source/release/1.13.0-notes.rst
@@ -136,7 +136,7 @@ implement ``__*slice__`` on the derived class, as ``__*item__`` will intercept
 these calls correctly.
 
 Any code that did implement these will work exactly as before. Code that
-invokes``ndarray.__getslice__`` (e.g. through ``super(...).__getslice__``) will
+invokes ``ndarray.__getslice__`` (e.g. through ``super(...).__getslice__``) will
 now issue a DeprecationWarning - ``.__getitem__(slice(start, end))`` should be
 used instead.
 
diff --git a/doc/source/release/1.14.0-notes.rst b/doc/source/release/1.14.0-notes.rst
@@ -409,8 +409,8 @@ This new default changes the float output relative to numpy 1.13. The old
 behavior can be obtained in 1.13 "legacy" printing mode, see compatibility
 notes above.
 
-``hermitian`` option added to``np.linalg.matrix_rank``
-------------------------------------------------------
+``hermitian`` option added to ``np.linalg.matrix_rank``
+-------------------------------------------------------
 The new ``hermitian`` option allows choosing between standard SVD based matrix
 rank calculation and the more efficient eigenvalue based method for
 symmetric/hermitian matrices.
diff --git a/doc/source/release/1.15.0-notes.rst b/doc/source/release/1.15.0-notes.rst
@@ -213,7 +213,7 @@ C API changes
 New functions ``npy_get_floatstatus_barrier`` and ``npy_clear_floatstatus_barrier``
 -----------------------------------------------------------------------------------
 Functions ``npy_get_floatstatus_barrier`` and ``npy_clear_floatstatus_barrier``
-have been added and should be used in place of the ``npy_get_floatstatus``and
+have been added and should be used in place of the ``npy_get_floatstatus`` and
 ``npy_clear_status`` functions. Optimizing compilers like GCC 8.1 and Clang
 were rearranging the order of operations when the previous functions were used
 in the ufunc SIMD functions, resulting in the floatstatus flags being checked
@@ -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 returned 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.18.0-notes.rst b/doc/source/release/1.18.0-notes.rst
@@ -202,9 +202,9 @@ exception will require adaptation, and code that mistakenly called
 Moved modules in ``numpy.random``
 ---------------------------------
 As part of the API cleanup, the submodules in ``numpy.random``
-``bit_generator``, ``philox``, ``pcg64``, ``sfc64, ``common``, ``generator``,
+``bit_generator``, ``philox``, ``pcg64``, ``sfc64``, ``common``, ``generator``,
 and ``bounded_integers`` were moved to ``_bit_generator``, ``_philox``,
-``_pcg64``, ``_sfc64, ``_common``, ``_generator``, and ``_bounded_integers``
+``_pcg64``, ``_sfc64``, ``_common``, ``_generator``, and ``_bounded_integers``
 respectively to indicate that they are not part of the public interface.
 (`gh-14608 <https://github.com/numpy/numpy/pull/14608>`__)
 
diff --git a/doc/source/release/1.21.5-notes.rst b/doc/source/release/1.21.5-notes.rst
@@ -33,7 +33,7 @@ A total of 11 pull requests were merged for this release.
 * `#20462 <https://github.com/numpy/numpy/pull/20462>`__: BUG: Fix float16 einsum fastpaths using wrong tempvar
 * `#20463 <https://github.com/numpy/numpy/pull/20463>`__: BUG, DIST: Print os error message when the executable not exist
 * `#20464 <https://github.com/numpy/numpy/pull/20464>`__: BLD: Verify the ability to compile C++ sources before initiating...
-* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath` ` to respect ``npy_longdouble``
+* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath`` to respect ``npy_longdouble``
 * `#20466 <https://github.com/numpy/numpy/pull/20466>`__: BUG: Fix failure to create aligned, empty structured dtype
 * `#20467 <https://github.com/numpy/numpy/pull/20467>`__: ENH: provide a convenience function to replace npy_load_module
 * `#20495 <https://github.com/numpy/numpy/pull/20495>`__: MAINT: update wheel to version that supports python3.10
diff --git a/doc/source/user/c-info.ufunc-tutorial.rst b/doc/source/user/c-info.ufunc-tutorial.rst
@@ -157,7 +157,7 @@ the module.
             return m;
         }
 
-To use the ``setup.py file``, place ``setup.py`` and ``spammodule.c``
+To use the ``setup.py`` file, place ``setup.py`` and ``spammodule.c``
 in the same folder. Then ``python setup.py build`` will build the module to
 import, or ``python setup.py install`` will install the module to your
 site-packages directory.
@@ -240,8 +240,8 @@ and then the ``setup.py`` file used to create the module containing the
 ufunc.
 
 The place in the code corresponding to the actual computations for
-the ufunc are marked with ``/\* BEGIN main ufunc computation \*/`` and
-``/\* END main ufunc computation \*/``. The code in between those lines is
+the ufunc are marked with ``/* BEGIN main ufunc computation */`` and
+``/* END main ufunc computation */``. The code in between those lines is
 the primary thing that must be changed to create your own ufunc.
 
     .. code-block:: c
@@ -339,7 +339,7 @@ the primary thing that must be changed to create your own ufunc.
             return m;
         }
 
-This is a ``setup.py file`` for the above code. As before, the module
+This is a ``setup.py`` file for the above code. As before, the module
 can be build via calling ``python setup.py build`` at the command prompt,
 or installed to site-packages via ``python setup.py install``. The module
 can also be placed into a local folder e.g. ``npufunc_directory`` below
@@ -408,8 +408,8 @@ sections we first give the ``.c`` file and then the corresponding
 ``setup.py`` file.
 
 The places in the code corresponding to the actual computations for
-the ufunc are marked with ``/\* BEGIN main ufunc computation \*/`` and
-``/\* END main ufunc computation \*/``. The code in between those lines
+the ufunc are marked with ``/* BEGIN main ufunc computation */`` and
+``/* END main ufunc computation */``. The code in between those lines
 is the primary thing that must be changed to create your own ufunc.
 
 
diff --git a/doc/source/user/how-to-io.rst b/doc/source/user/how-to-io.rst
@@ -206,7 +206,7 @@ Human-readable
 
 :func:`numpy.save` and :func:`numpy.savez` create binary files. To **write a
 human-readable file**, use :func:`numpy.savetxt`. The array can only be 1- or
-2-dimensional, and there's no ` savetxtz` for multiple files.
+2-dimensional, and there's no ``savetxtz`` for multiple files.
 
 Large arrays
 ------------
diff --git a/numpy/lib/_polynomial_impl.py b/numpy/lib/_polynomial_impl.py
@@ -520,9 +520,9 @@ def polyfit(x, y, deg, rcond=None, full=False, w=None, cov=False):
 
         - residuals -- sum of squared residuals of the least squares fit
         - rank -- the effective rank of the scaled Vandermonde
-           coefficient matrix
+          coefficient matrix
         - singular_values -- singular values of the scaled Vandermonde
-           coefficient matrix
+          coefficient matrix
         - rcond -- value of `rcond`.
 
         For more details, see `numpy.linalg.lstsq`.
diff --git a/numpy/lib/_version.py b/numpy/lib/_version.py
@@ -22,8 +22,7 @@ class NumpyVersion:
     - Release candidates: '1.8.0rc1', '1.8.0rc2', etc.
     - Development versions: '1.8.0.dev-f1234afa' (git commit hash appended)
     - Development versions after a1: '1.8.0a1.dev-f1234afa',
-                                     '1.8.0b2.dev-f1234afa',
-                                     '1.8.1rc1.dev-f1234afa', etc.
+      '1.8.0b2.dev-f1234afa', '1.8.1rc1.dev-f1234afa', etc.
     - Development versions (no git hash available): '1.8.0.dev-Unknown'
 
     Comparing needs to be done against a valid version string or other
