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,22 +520,22 @@ 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>`_
+* 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>`_:
+* .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()>`_:
+* 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>`_:
+* 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
 

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-0446.txt

@@ -308,17 +308,17 @@ 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),
+* ``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()``,
+* ``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,
+* ``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
+* ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
   and Solaris 11.
- * ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
+* ``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

pep-0495.txt

@@ -676,7 +676,7 @@ default value.
 
 The following alternative names have also been considered:
 
-  **later**
+**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
@@ -686,15 +686,15 @@ The following alternative names have also been considered:
     Yet again, this can be interpreted as a desirable indication that
     the original time is invalid.
 
-  **which**
+**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**
+**repeated**
     Did not receive any support on the mailing list.
 
-  **ltdf**
+**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

pep-0498.txt

@@ -616,10 +616,10 @@ 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
+- 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
+- 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

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-3141.txt

@@ -467,17 +467,17 @@ 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
+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
+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
+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.
 

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