From 76159afb05c3ef7045bb1101fc00ecc7942ed5c2 Mon Sep 17 00:00:00 2001
From: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Date: Fri, 1 Sep 2023 20:27:45 +0100
Subject: [PATCH] PEP 3149: Resolve uses of the default role (#3401)

---
 pep-3149.txt | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/pep-3149.txt b/pep-3149.txt
index a7d64707c..9d0f3a2ad 100644
--- a/pep-3149.txt
+++ b/pep-3149.txt
@@ -30,8 +30,8 @@ Background
 
 :pep:`3147` defined the file system layout for a pure-Python package,
 where multiple versions of Python are available on the system.  For
-example, where the `alpha` package containing source modules `one.py`
-and `two.py` exist on a system with Python 3.2 and 3.3, the post-byte
+example, where the ``alpha`` package containing source modules ``one.py``
+and ``two.py`` exist on a system with Python 3.2 and 3.3, the post-byte
 compilation file system layout would be::
 
     alpha/
@@ -69,18 +69,18 @@ with Python 2.6 being the default.
 
 In order to share as much as possible between the available Python
 versions, these distributions install third party package modules
-(``.pyc`` and ``.so`` files) into `/usr/share/pyshared` and symlink to
-them from `/usr/lib/pythonX.Y/dist-packages`.  The symlinks exist
-because in a pre-:pep:`3147` world (i.e < Python 3.2), the `.pyc` files
+(``.pyc`` and ``.so`` files) into ``/usr/share/pyshared`` and symlink to
+them from ``/usr/lib/pythonX.Y/dist-packages``.  The symlinks exist
+because in a pre-:pep:`3147` world (i.e < Python 3.2), the ``.pyc`` files
 resulting from byte compilation by the various installed Pythons will
 name collide with each other.  For Python versions >= 3.2, all
-pure-Python packages can be shared, because the `.pyc` files will no
+pure-Python packages can be shared, because the ``.pyc`` files will no
 longer cause file system naming conflicts.  Eliminating these symlinks
 makes for a simpler, more robust Python distribution.
 
 A similar situation arises with shared library extensions.  Because
-extension modules are typically named `foo.so` for a `foo` extension
-module, these would also name collide if `foo` was provided for more
+extension modules are typically named ``foo.so`` for a ``foo`` extension
+module, these would also name collide if ``foo`` was provided for more
 than one Python version.
 
 In addition, because different configuration/compilation options for
@@ -93,7 +93,7 @@ module files.
 
 PyPy [5]_ can also benefit from this PEP, allowing it to avoid name
 collisions in extension modules built for its API, but with a
-different `.so` tag.
+different ``.so`` tag.
 
 
 Proposal
@@ -139,7 +139,7 @@ Note that ``$SOABI`` contains just the tag, while ``$EXT_SUFFIX`` includes the
 platform extension for shared library files, and is the exact suffix
 added to the extension module name.
 
-For an arbitrary package `foo`, you might see these files when the
+For an arbitrary package ``foo``, you might see these files when the
 distribution package was installed::
 
     /usr/lib/python/foo.cpython-32m.so
@@ -159,7 +159,7 @@ This shared library tag would be used globally for all distutils-based
 extension modules, regardless of where on the file system they are
 built.  Extension modules built by means other than distutils would
 either have to calculate the tag manually, or fallback to the
-non-tagged `.so` file name.
+non-tagged ``.so`` file name.
 
 
 Proven approach
@@ -170,7 +170,7 @@ and Ubuntu system where different extensions are used for debug builds
 of Python and extension modules.  Debug builds on Windows also already
 use a different file extension for dynamic libraries, and in fact
 encoded (in a different way than proposed in this PEP) the Python
-major and minor version in the `.dll` file name.
+major and minor version in the ``.dll`` file name.
 
 
 Windows
@@ -207,7 +207,7 @@ its name.  The prefix ``abi`` is reserved for Python's use.
 
 Thus, an initial implementation of :pep:`384`, when Python is configured
 with the default set of flags, would search for the following file
-names when extension module `foo` is imported (in this order)::
+names when extension module ``foo`` is imported (in this order)::
 
     foo.cpython-XYm.so
     foo.abi3.so
@@ -271,7 +271,7 @@ If a pure-Python package is shared in one version, should it suddenly
 be not-shared if the next release adds an extension module for speed?
 Also, even though all extension shared libraries will be compiled and
 distributed once for every supported Python, there's a big difference
-between duplicating the `.so` files and duplicating all `.py` files.
+between duplicating the ``.so`` files and duplicating all ``.py`` files.
 The extra size increases the download time for such packages, and more
 immediately, increases the space pressures on already constrained
 distribution CD-ROMs.