PEP 101: Resolve uses of the default role (#3368)

pep-0101.txt

@@ -212,7 +212,7 @@ to perform some manual editing steps.
   within it (called the "release clone" from now on).  You can use the same
   GitHub fork you use for cpython development.  Using the standard setup
   recommended in the Python Developer's Guide, your fork would be referred
-  to as `origin` and the standard cpython repo as `upstream`.  You will
+  to as ``origin`` and the standard cpython repo as ``upstream``.  You will
   use the branch on your fork to do the release engineering work, including
   tagging the release, and you will use it to share with the other experts
   for making the binaries.
@@ -302,7 +302,7 @@ to perform some manual editing steps.
 
       $ .../release-tools/release.py --tag X.Y.ZaN
 
-  This executes a `git tag` command with the `-s` option so that the
+  This executes a ``git tag`` command with the ``-s`` option so that the
   release tag in the repo is signed with your gpg key.  When prompted
   choose the private key you use for signing release tarballs etc.
 
@@ -538,7 +538,7 @@ the main repo.
   do some post-merge cleanup.  Check the top-level ``README.rst``
   and ``include/patchlevel.h`` files to ensure they now reflect
   the desired post-release values for on-going development.
-  The patchlevel should be the release tag with a `+`.
+  The patchlevel should be the release tag with a ``+``.
   Also, if you cherry-picked changes from the standard release
   branch into the release engineering branch for this release,
   you will now need to manual remove each blurb entry from
@@ -546,8 +546,8 @@ the main repo.
   into the release you are working on since that blurb entry
   is now captured in the merged x.y.z.rst file for the new
   release.  Otherwise, the blurb entry will appear twice in
-  the `changelog.html` file, once under `Python next` and again
-  under `x.y.z`.
+  the ``changelog.html`` file, once under ``Python next`` and again
+  under ``x.y.z``.
 
 - Review and commit these changes::
 
@@ -712,19 +712,19 @@ with RevSys.)
 - If this is a **final** release:
 
   - Add the new version to the *Python Documentation by Version*
-    page `https://www.python.org/doc/versions/` and
+    page ``https://www.python.org/doc/versions/`` and
     remove the current version from any 'in development' section.
 
   - For X.Y.Z, edit all the previous X.Y releases' page(s) to
     point to the new release.  This includes the content field of the
-    `Downloads -> Releases` entry for the release::
+    ``Downloads -> Releases`` entry for the release::
 
       Note: Python x.y.m has been superseded by
       `Python x.y.n </downloads/release/python-xyn/>`_.
 
     And, for those releases having separate release page entries
     (phasing these out?), update those pages as well,
-    e.g. `download/releases/x.y.z`::
+    e.g. ``download/releases/x.y.z``::
 
       Note: Python x.y.m has been superseded by
       `Python x.y.n </download/releases/x.y.n/>`_.
@@ -908,8 +908,8 @@ else does them.  Some of those tasks include:
 
 - Remove the release from the list of "Active Python Releases" on the Downloads
   page.  To do this, log in to the admin page for python.org, navigate to Boxes,
-  and edit the `downloads-active-releases` entry.  Simply strip out the relevant
-  paragraph of HTML for your release.  (You'll probably have to do the `curl -X PURGE`
+  and edit the ``downloads-active-releases`` entry.  Simply strip out the relevant
+  paragraph of HTML for your release.  (You'll probably have to do the ``curl -X PURGE``
   trick to purge the cache if you want to confirm you made the change correctly.)
 
 - Add retired notice to each release page on python.org for the retired branch.