diff --git a/pep-0432.txt b/pep-0432.txt
index 76410a65f4b..2f9baa98df0 100644
--- a/pep-0432.txt
+++ b/pep-0432.txt
@@ -13,6 +13,7 @@ Requires: 587
 Created: 28-Dec-2012
 Post-History: 28-Dec-2012, 02-Jan-2013, 30-Mar-2019, 28-Jun-2020
 
+.. highlight:: c
 
 PEP Withdrawal
 ==============
@@ -151,10 +152,10 @@ Background
 
 Over time, CPython's initialization sequence has become progressively more
 complicated, offering more options, as well as performing more complex tasks
-(such as configuring the Unicode settings for OS interfaces in Python 3 [10_],
+(such as configuring the Unicode settings for OS interfaces in Python 3 [10]_,
 bootstrapping a pure Python implementation of the import system, and
 implementing an isolated mode more suitable for system applications that run
-with elevated privileges [6_]).
+with elevated privileges [6]_).
 
 Much of this complexity is formally accessible only through the ``Py_Main``
 and ``Py_Initialize`` APIs, offering embedding applications little
@@ -166,9 +167,9 @@ API cannot be used safely.
 A number of proposals are on the table for even *more* sophisticated
 startup behaviour, such as better control over ``sys.path``
 initialization (e.g. easily adding additional directories on the command line
-in a cross-platform fashion [7_], controlling the configuration of
-``sys.path[0]`` [8_]), easier configuration of utilities like coverage
-tracing when launching Python subprocesses [9_]).
+in a cross-platform fashion [7]_, controlling the configuration of
+``sys.path[0]`` [8]_), easier configuration of utilities like coverage
+tracing when launching Python subprocesses [9]_).
 
 Rather than continuing to bolt such behaviour onto an already complicated
 system indefinitely, this PEP proposes to start simplifying the status quo by
@@ -195,7 +196,7 @@ The CPython startup sequence as of Python 3.6 was difficult to understand, and
 even more difficult to modify. It was not clear what state the interpreter was
 in while much of the initialization code executed, leading to behaviour such
 as lists, dictionaries and Unicode values being created prior to the call
-to ``Py_Initialize`` when the ``-X`` or ``-W`` options are used [1_].
+to ``Py_Initialize`` when the ``-X`` or ``-W`` options are used [1]_.
 
 By moving to an explicitly multi-phase startup sequence, developers should
 only need to understand:
@@ -238,11 +239,15 @@ should minimise their impact on the startup overhead.
 Experience with the importlib migration suggests that the startup time is
 dominated by IO operations. However, to monitor the impact of any changes,
 a simple benchmark can be used to check how long it takes to start and then
-tear down the interpreter::
+tear down the interpreter:
+
+.. code-block:: bash
 
    python3 -m timeit -s "from subprocess import call" "call(['./python', '-Sc', 'pass'])"
 
-Current numbers on my system for Python 3.7 (as built by the Fedora project)::
+Current numbers on my system for Python 3.7 (as built by the Fedora project):
+
+.. code-block:: shell
 
     $ python3 -m timeit -s "from subprocess import call" "call(['python3', '-Sc', 'pass'])"
     50 loops, best of 5: 6.48 msec per loop
@@ -269,7 +274,7 @@ Implementation Strategy
 =======================
 
 An initial attempt was made at implementing an earlier version of this PEP for
-Python 3.4 [2_], with one of the significant problems encountered being merge
+Python 3.4 [2]_, with one of the significant problems encountered being merge
 conflicts after the initial structural changes were put in place to start the
 refactoring process. Unlike some other previous major changes, such as the
 switch to an AST-based compiler in Python 2.5, or the switch to the importlib
@@ -1069,7 +1074,7 @@ aspects are the fact that user site directories are enabled,
 environment variables are trusted and that the directory containing the
 executed file is placed at the beginning of the import path.
 
-Issue 16499 [6_] added a ``-I`` option to change the behaviour of
+Issue 16499 [6]_ added a ``-I`` option to change the behaviour of
 the normal CPython executable, but this is a hard to discover solution (and
 adds yet another option to an already complex CLI). This PEP proposes to
 instead add a separate ``system-python`` executable
@@ -1173,7 +1178,7 @@ Locating Python and the standard library
 
 The location of the Python binary and the standard library is influenced
 by several elements. The algorithm used to perform the calculation is
-not documented anywhere other than in the source code [3_,4_]. Even that
+not documented anywhere other than in the source code [3]_, [4]_. Even that
 description is incomplete, as it failed to be updated for the virtual
 environment support added in Python 3.3 (detailed in :pep:`405`).
 
@@ -1213,7 +1218,7 @@ the ``PYTHONPATH`` environment variable.
 
 The ``site`` module, which is implicitly imported at startup (unless
 disabled via the ``-S`` option) adds additional paths to this initial
-set of paths, as described in its documentation [5_].
+set of paths, as described in its documentation [5]_.
 
 The ``-s`` command line option can be used to exclude the user site
 directory from the list of directories added. Embedding applications
@@ -1372,7 +1377,7 @@ connection by the operating system.
 TBD: Document how the "-x" option is handled (skips processing of the
 first comment line in the main script)
 
-Also see detailed sequence of operations notes at [1_]
+Also see detailed sequence of operations notes at [1]_.
 
 
 References