Apply suggestions from code review

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>

Author: zooba

peps/pep-0772.rst

@@ -140,12 +140,12 @@ release process using almost all identical binaries to the other packages.
 Due to being in an app store package, the primary ``python.exe`` is enhanced
 to be able to determine its location properly, and alternative ``pip.exe`` and
 other shortcuts are included to make up for the lack of ``PATH`` environment
-variable settings. These are implemented in ``PC\\python_uwp.cpp`` in our repo.
+variable settings. These are implemented in :file:`PC\\python_uwp.cpp` in our repo.
 
 These packages are installed by searching for Python in the Microsoft Store
 app, which will find results for each major version since 3.8. Users then have
 to select a version and install it. These packages include the CPython
-interpreter, standard library, Tcl/Tk, IDLE and pip, and create file
+interpreter, standard library, Tcl/Tk, IDLE, and pip, and create file
 associations, Start Menu shortcuts, and global commands for ``python.exe``,
 ``python3.exe``, ``python3.X.exe``, ``pip[3[.X]].exe`` and ``idle[3[.X]].exe``.
 No ``PATH`` modification is possible or required, though users may need to
@@ -271,7 +271,7 @@ example, if the user has Python 3.14 installed and then installs (or updates)
 3.13, the ``python`` command will switch from the later version to the earlier
 version.
 
-The ``py.exe`` launcher, defined in PEP 397 and implicitly updated by PEP 514,
+The ``py.exe`` launcher, defined in :pep:`397` and implicitly updated by :pep:`514`,
 is an attempt to avoid this particular issue. It uses its own logic for finding
 installed versions without relying on ``PATH``. However, the PEP 514 logic does
 not allow for prerelease or experimental builds to be treated specially, and so
@@ -340,17 +340,17 @@ ability to inspect the user's system and choose the correct runtime to launch.
 Additionally, ``py`` and ``pymanager`` will have management subcommands to allow
 adding and removing runtimes.
 
-In line with PEP 394 and the default behaviour of Windows, the recommended
+In line with :pep:`394` and the default behaviour of Windows, the recommended
 command for launching Python is ``python.exe``. As provided by PyManager, this
 will locate an existing install, either among those that PyManager manages or
-using PEP 514, or it will install the latest available version of CPython and
+using :pep:`514`, or it will install the latest available version of CPython and
 select that. The ``python3.exe`` command behaves similarly, but is only allowed
 to find 3.x installs from python.org.
 
 The ``py.exe`` command provided by PyManager will be recommended for most
 management use, due to its brevity. ``py install ...``, ``py list ...`` and so
 on. The proposed commands are detailed later. The existing behaviour of the
-PEP 397 launcher is preserved, however, launching through ``py`` will not
+:pep:`397` launcher is preserved, however, launching through ``py`` will not
 automatically install runtimes (by default). If one is requested but is not
 installed, users will just get an error. The ``py run ...`` subcommand, however,
 will install automatically, and supports the same options as bare ``py``.
@@ -378,7 +378,7 @@ Replacing other installers
 
 Our intent is to immediately stop publishing individual versions to the Windows
 Store, and to deprecate and phase out the traditional installer and Nuget
-packages by 3.16. The embeddable distro would remain, but its listing on
+packages by Python 3.16. The embeddable distro would remain, but its listing on
 python.org download pages would be phased out and it will be available only
 through PyManager.
 
@@ -773,7 +773,9 @@ versions. The intent is to allow for older indexes to be archived and only
 accessed when required, reducing the size of the initial download without
 cutting off users from older versions.
 
-The initial schema is shown below::
+The initial schema is shown below:
+
+.. code:: python
 
    SCHEMA = {
        "versions": [