Cleanup. Add double backticks where needed.

pep-0420.txt

@@ -15,7 +15,7 @@ Abstract
 
 Namespace packages are a mechanism for splitting a single Python
 package across multiple directories on disk. In current Python
-versions, an algorithm to compute the packages __path__ must be
+versions, an algorithm to compute the packages ``__path__`` must be
 formulated. With the enhancement proposed here, the import machinery
 itself will construct the list of directories that make up the
 package.  This PEP builds upon the work started in rejected PEPs 382
@@ -24,19 +24,20 @@ and 402.
 Terminology
 ===========
 
-Within this PEP, the term "package" refers to Python packages as defined
-by Python's import statement. The term "distribution" refers to
-separately installable sets of Python modules as stored in the Python
-package index, and installed by distutils or setuptools. The term
-"vendor package" refers to groups of files installed by an operating
-system's packaging mechanism (e.g. Debian or Redhat packages install
-on Linux systems).
+Within this PEP:
 
-The term "portion" refers to a set of files in a single directory (possibly
-stored in a zip file) that contribute to a namespace package.
-
-The term "regular package" refers to packages as they are implemented
-in Python 3.2.
+ * "package" refers to Python packages as defined by Python's import
+   statement.
+ * "distribution" refers to separately installable sets of Python
+   modules as stored in the Python package index, and installed by
+   distutils or setuptools.
+ * "vendor package" refers to groups of files installed by an
+   operating system's packaging mechanism (e.g. Debian or Redhat
+   packages install on Linux systems).
+ * "portion" refers to a set of files in a single directory (possibly
+   stored in a zip file) that contribute to a namespace package.
+ * "regular package" refers to packages as they are implemented in
+   Python 3.2.
 
 This PEP describes a new type of package, the "namespace package".
 
@@ -59,20 +60,21 @@ feature, extend_path reads files named ``<packagename>.pkg`` which
 allow to declare additional portions.
 
 setuptools provides a similar function named
-pkg_resources.declare_namespace that is used in the form::
+``pkg_resources.declare_namespace`` that is used in the form::
 
     import pkg_resources
     pkg_resources.declare_namespace(__name__)
 
-In the portion's __init__.py, no assignment to __path__ is necessary,
-as declare_namespace modifies the package __path__ through sys.modules.
-As a special feature, declare_namespace also supports zip files, and
-registers the package name internally so that future additions to sys.path
-by setuptools can properly add additional portions to each package.
+In the portion's ``__init__.py``, no assignment to ``__path__`` is
+necessary, as ``declare_namespace`` modifies the package ``__path__``
+through ``sys.modules``. As a special feature, ``declare_namespace``
+also supports zip files, and registers the package name internally so
+that future additions to ``sys.path`` by setuptools can properly add
+additional portions to each package.
 
 setuptools allows declaring namespace packages in a distribution's
-setup.py, so that distribution developers don't need to put the
-magic __path__ modification into __init__.py themselves.
+``setup.py``, so that distribution developers don't need to put the
+magic ``__path__`` modification into ``__init__.py`` themselves.
 
 Rationale
 =========
@@ -81,8 +83,8 @@ The current imperative approach to namespace packages has lead to
 multiple slightly-incompatible mechanisms for providing namespace
 packages. For example, pkgutil supports ``*.pkg`` files; setuptools
 doesn't. Likewise, setuptools supports inspecting zip files, and
-supports adding portions to its _namespace_packages variable, whereas
-pkgutil doesn't.
+supports adding portions to its ``_namespace_packages`` variable,
+whereas pkgutil doesn't.
 
 Namespace packages are designed to support being split across multiple
 directories (and hence found via multiple sys.path entries).  In this
@@ -102,29 +104,30 @@ fit.
 Specification
 =============
 
-Regular packages will continue to have an __init__.py and will reside
-in a single directory.
+Regular packages will continue to have an ``__init__.py`` and will
+reside in a single directory.
 
-Namespace packages cannot contain an __init__.py. As a consequence,
-extend_path and declare_namespace become obsolete. There will be no
-marker file or directory for specifing a namespace package.
+Namespace packages cannot contain an ``__init__.py``. As a
+consequence, ``extend_path`` and ``declare_namespace`` become
+obsolete. There will be no marker file or directory for specifing a
+namespace package.
 
 During import processing, the import machinery will continue to
 iterate over the parent path as it does in Python 3.2. While looking
 for a module or package named "foo":
 
- * If foo/__init__.py is found, a regular package is imported.
- * If not, but foo.{py,pyc,so,pyd} is found, a module is imported.
- * If not, but foo is found and is a directory, it is recorded.
+ * If ``foo/__init__.py`` is found, a regular package is imported.
+ * If not, but ``foo.{py,pyc,so,pyd}`` is found, a module is imported.
+ * If not, but ``foo`` is found and is a directory, it is recorded.
 
 If the scan along the parent path completes without finding a module
 or package, then a namespace package is created. The new namespace
 package:
 
- * Has a __file__ set to the first directory that was found during the
-   scan, including the trailing path separator.
- * Has a __path__ set to the list of directories there were found and
-   recorded during the scan.
+ * Has a ``__file__`` attribute set to the first directory that was
+   found during the scan, including the trailing path separator.
+ * Has a ``__path__`` attribute set to the list of directories there
+   were found and recorded during the scan.
 
 There is no mechanism to automatically recompute the ``__path__`` if
 ``sys.path`` is altered after a namespace package has already been