Fixup some more lists-in-blockquotes. Fixes #26914.

pep-0318.txt

@@ -396,7 +396,7 @@ apply to the previous form) as:
     http://mail.python.org/pipermail/python-dev/2004-August/047112.html
 
 The next form is that the decorator syntax goes inside the method body at
-the start, in the same place that docstrings currently live:
+the start, in the same place that docstrings currently live::
 
     def foo(arg1,arg2):
         @classmethod

pep-0410.txt

@@ -425,7 +425,7 @@ the specified type. If the type doesn't support the protocol, a fallback is
 used: type(numerator) / type(denominator).
 
 A variant is to use a "converter" callback to create a timestamp. Example
-creating a float timestamp:
+creating a float timestamp::
 
     def timestamp_to_float(numerator, denominator):
         return float(numerator) / float(denominator)
@@ -520,24 +520,24 @@ Links
 
 Python:
 
- * `Issue #7652: Merge C version of decimal into py3k <http://bugs.python.org/issue7652>`_ (cdecimal)
- * `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution <http://bugs.python.org/issue11457>`_
- * `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps <http://bugs.python.org/issue13882>`_
- * `[Python-Dev] Store timestamps as decimal.Decimal objects <http://mail.python.org/pipermail/python-dev/2012-January/116025.html>`_
+* `Issue #7652: Merge C version of decimal into py3k <http://bugs.python.org/issue7652>`_ (cdecimal)
+* `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution <http://bugs.python.org/issue11457>`_
+* `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps <http://bugs.python.org/issue13882>`_
+* `[Python-Dev] Store timestamps as decimal.Decimal objects <http://mail.python.org/pipermail/python-dev/2012-January/116025.html>`_
 
 Other languages:
 
- * Ruby (1.9.3), the `Time class <http://ruby-doc.org/core-1.9.3/Time.html>`_
-   supports picosecond (10\ :sup:`-12`)
- * .NET framework, `DateTime type <http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx>`_:
-   number of 100-nanosecond intervals that have elapsed since 12:00:00
-   midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
- * Java (1.5), `System.nanoTime() <http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()>`_:
-   wallclock with an unspecified starting point as a number of nanoseconds, use
-   a signed 64 bits integer (long).
- * Perl, `Time::Hiref module <http://perldoc.perl.org/Time/HiRes.html>`_:
-   use float so has the same loss of precision issue with nanosecond resolution
-   than Python float timestamps
+* Ruby (1.9.3), the `Time class <http://ruby-doc.org/core-1.9.3/Time.html>`_
+  supports picosecond (10\ :sup:`-12`)
+* .NET framework, `DateTime type <http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx>`_:
+  number of 100-nanosecond intervals that have elapsed since 12:00:00
+  midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
+* Java (1.5), `System.nanoTime() <http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()>`_:
+  wallclock with an unspecified starting point as a number of nanoseconds, use
+  a signed 64 bits integer (long).
+* Perl, `Time::Hiref module <http://perldoc.perl.org/Time/HiRes.html>`_:
+  use float so has the same loss of precision issue with nanosecond resolution
+  than Python float timestamps
 
 
 Copyright

pep-0422.txt

@@ -130,7 +130,7 @@ class initialisation hook as follows::
            return cls
 
 To simplify the cooperative multiple inheritance case, ``object`` will gain
-a default implementation of the hook that returns the class unmodified:
+a default implementation of the hook that returns the class unmodified::
 
    class object:
        def __autodecorate__(cls):

pep-0436.txt

@@ -517,10 +517,10 @@ parameters, on an individual basis:
   A list of strings representing acceptable Python types for this object.
   There are also four strings which represent Python protocols:
 
-    * "buffer"
-    * "mapping"
-    * "number"
-    * "sequence"
+  * "buffer"
+  * "mapping"
+  * "number"
+  * "sequence"
 
 ``zeroes``
   For converters that accept string types.  The converted value should

pep-0446.txt

@@ -308,18 +308,18 @@ version (ex: Windows XP SP3), ``WSASocket()`` fails with
 
 On UNIX, new flags were added for files and sockets:
 
- * ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
-   Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
-   (6.1?). This flag is part of POSIX.1-2008.
- * ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
-   available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
- * ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
-   OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
-   of POSIX.1-2008.
- * ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
-   and Solaris 11.
- * ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
-   NetBSD 6.0.
+* ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
+  Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
+  (6.1?). This flag is part of POSIX.1-2008.
+* ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
+  available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
+* ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
+  OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
+  of POSIX.1-2008.
+* ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
+  and Solaris 11.
+* ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
+  NetBSD 6.0.
 
 On Linux older than 2.6.23, ``O_CLOEXEC`` flag is simply ignored. So
 ``fcntl()`` must be called to check if the file descriptor is

pep-0495.txt

@@ -676,29 +676,29 @@ default value.
 
 The following alternative names have also been considered:
 
-  **later**
-      A close contender to "fold".  One author dislikes it because
-      it is confusable with equally fitting "latter," but in the age
-      of auto-completion everywhere this is a small consideration.  A
-      stronger objection may be that in the case of missing time, we
-      will have ``later=True`` instance converted to an earlier time by
-      ``.astimezone(timezone.utc)`` that that with ``later=False``.
-      Yet again, this can be interpreted as a desirable indication that
-      the original time is invalid.
+**later**
+    A close contender to "fold".  One author dislikes it because
+    it is confusable with equally fitting "latter," but in the age
+    of auto-completion everywhere this is a small consideration.  A
+    stronger objection may be that in the case of missing time, we
+    will have ``later=True`` instance converted to an earlier time by
+    ``.astimezone(timezone.utc)`` that that with ``later=False``.
+    Yet again, this can be interpreted as a desirable indication that
+    the original time is invalid.
 
-  **which**
-      The `original`_ placeholder name for the `localtime` function
-      branch index was `independently proposed`_ for the name of the
-      disambiguation attribute and received `some support`_.
+**which**
+    The `original`_ placeholder name for the `localtime` function
+    branch index was `independently proposed`_ for the name of the
+    disambiguation attribute and received `some support`_.
 
-  **repeated**
-      Did not receive any support on the mailing list.
+**repeated**
+    Did not receive any support on the mailing list.
 
-  **ltdf**
-      (Local Time Disambiguation Flag) - short and no-one will attempt
-      to guess what it means without reading the docs.  (This abbreviation
-      was used in PEP discussions with the meaning ``ltdf=False`` is the
-      earlier by those who didn't want to endorse any of the alternatives.)
+**ltdf**
+    (Local Time Disambiguation Flag) - short and no-one will attempt
+    to guess what it means without reading the docs.  (This abbreviation
+    was used in PEP discussions with the meaning ``ltdf=False`` is the
+    earlier by those who didn't want to endorse any of the alternatives.)
 
 .. _original: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
 .. _independently proposed: https://mail.python.org/pipermail/datetime-sig/2015-August/000479.html

pep-0498.txt

@@ -616,11 +616,11 @@ Binary f-strings would first require a solution for
 recently in PEP 461 [#]_. The discussions of such a feature usually
 suggest either
 
-  - adding a method such as ``__bformat__()`` so an object can control
-    how it is converted to bytes, or
+- adding a method such as ``__bformat__()`` so an object can control
+  how it is converted to bytes, or
 
-  - having ``bytes.format()`` not be as general purpose or extensible
-    as ``str.format()``.
+- having ``bytes.format()`` not be as general purpose or extensible
+  as ``str.format()``.
 
 Both of these remain as options in the future, if such functionality
 is desired.

pep-3104.txt

@@ -190,9 +190,9 @@ The proposals in this category all suggest a new kind of declaration
 statement similar to JavaScript's ``var``.  A few possible keywords
 have been proposed for this purpose:
 
-    - ``scope x`` [4]_
-    - ``var x`` [4]_ [9]_
-    - ``my x`` [13]_
+- ``scope x`` [4]_
+- ``var x`` [4]_ [9]_
+- ``my x`` [13]_
 
 In all these proposals, a declaration such as ``var x`` in a
 particular scope S would cause all references to ``x`` in scopes

pep-3108.txt

@@ -431,11 +431,11 @@ A stub module for proxy access will be provided for use by urllib.
 
 * videoreader
 
-   - No longer used.
+  - No longer used.
 
 * W
 
-   - No longer distributed with Python.
+  - No longer distributed with Python.
 
 
 .. _PyObjC: http://pyobjc.sourceforge.net/
@@ -1051,7 +1051,7 @@ Modules that were originally suggested for removal
 
 * audioop/sunau/aifc
 
-   + Audio modules where the formats are still used.
+  + Audio modules where the formats are still used.
 
 * base64/quopri/uu
 
@@ -1065,7 +1065,7 @@ Modules that were originally suggested for removal
 
 * linecache
 
-   + Used internally in several places.
+  + Used internally in several places.
 
 * nis
 

pep-3127.txt

@@ -179,7 +179,7 @@ the string representation of integers relate to these features:
   by eval(), and by int(token, 0).  (int(token) and int(token, 2-36)
   are not modified by this proposal.)
 
-       * Under 2.6, long() is treated the same as int()
+  * Under 2.6, long() is treated the same as int()
 
 - Formatting of integers into strings, either via the % string
   operator or the new PEP 3101 advanced string formatting method.

pep-3141.txt

@@ -467,19 +467,19 @@ MyIntegral and OtherTypeIKnowAbout as "boilerplate". ``a`` will be an
 instance of ``A``, which is a subtype of ``Complex`` (``a : A <:
 Complex``), and ``b : B <: Complex``. I'll consider ``a + b``:
 
-    1. If A defines an __add__ which accepts b, all is well.
-    2. If A falls back to the boilerplate code, and it were to return
-       a value from __add__, we'd miss the possibility that B defines
-       a more intelligent __radd__, so the boilerplate should return
-       NotImplemented from __add__. (Or A may not implement __add__ at
-       all.)
-    3. Then B's __radd__ gets a chance. If it accepts a, all is well.
-    4. If it falls back to the boilerplate, there are no more possible
-       methods to try, so this is where the default implementation
-       should live.
-    5. If B <: A, Python tries B.__radd__ before A.__add__. This is
-       ok, because it was implemented with knowledge of A, so it can
-       handle those instances before delegating to Complex.
+1. If A defines an __add__ which accepts b, all is well.
+2. If A falls back to the boilerplate code, and it were to return
+   a value from __add__, we'd miss the possibility that B defines
+   a more intelligent __radd__, so the boilerplate should return
+   NotImplemented from __add__. (Or A may not implement __add__ at
+   all.)
+3. Then B's __radd__ gets a chance. If it accepts a, all is well.
+4. If it falls back to the boilerplate, there are no more possible
+   methods to try, so this is where the default implementation
+   should live.
+5. If B <: A, Python tries B.__radd__ before A.__add__. This is
+   ok, because it was implemented with knowledge of A, so it can
+   handle those instances before delegating to Complex.
 
 If ``A<:Complex`` and ``B<:Real`` without sharing any other knowledge,
 then the appropriate shared operation is the one involving the built

pep-3149.txt

@@ -107,8 +107,8 @@ name and the operation file system extension for shared libraries.
 The following information *MUST* be included in the shared library
 file name:
 
- * The Python implementation (e.g. cpython, pypy, jython, etc.)
- * The interpreter's major and minor version numbers
+* The Python implementation (e.g. cpython, pypy, jython, etc.)
+* The interpreter's major and minor version numbers
 
 These two fields are separated by a hyphen and no dots are to appear
 between the major and minor version numbers.  E.g. ``cpython-32``.

pep-3156.txt

@@ -1386,10 +1386,10 @@ context.  (See the "Context" section way above.)
 Here is a table indicating the order and multiplicity of the basic
 calls:
 
-  1. ``connection_made()`` -- exactly once
-  2. ``data_received()`` -- zero or more times
-  3. ``eof_received()`` -- at most once
-  4. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``data_received()`` -- zero or more times
+3. ``eof_received()`` -- at most once
+4. ``connection_lost()`` -- exactly once
 
 Calls to ``pause_writing()`` and ``resume_writing()`` occur in pairs
 and only between #1 and #4.  These pairs will not be nested.  The
@@ -1418,9 +1418,9 @@ In addition, they have the following methods:
 
 Here is a chart indicating the order and multiplicity of calls:
 
-  1. ``connection_made()`` -- exactly once
-  2. ``datagram_received()``, ``error_received()`` -- zero or more times
-  3. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``datagram_received()``, ``error_received()`` -- zero or more times
+3. ``connection_lost()`` -- exactly once
 
 
 Subprocess Protocol