Merge pull request #1489 from edgarrmondragon/intersphinx-more-links

Use intersphinx to link to other Python docs

Author: webknjaz

source/specifications/dependency-specifiers.rst

@@ -234,37 +234,37 @@ error like all other unknown variables.
      - Python equivalent
      - Sample values
    * - ``os_name``
-     - ``os.name``
+     - :py:data:`os.name`
      - ``posix``, ``java``
    * - ``sys_platform``
-     - ``sys.platform``
+     - :py:data:`sys.platform`
      - ``linux``, ``linux2``, ``darwin``, ``java1.8.0_51`` (note that "linux"
        is from Python3 and "linux2" from Python2)
    * - ``platform_machine``
-     - ``platform.machine()``
+     - :py:func:`platform.machine()`
      - ``x86_64``
    * - ``platform_python_implementation``
-     - ``platform.python_implementation()``
+     - :py:func:`platform.python_implementation()`
      - ``CPython``, ``Jython``
    * - ``platform_release``
-     - ``platform.release()``
+     - :py:func:`platform.release()`
      - ``3.14.1-x86_64-linode39``, ``14.5.0``, ``1.8.0_51``
    * - ``platform_system``
-     - ``platform.system()``
+     - :py:func:`platform.system()`
      - ``Linux``, ``Windows``, ``Java``
    * - ``platform_version``
-     - ``platform.version()``
+     - :py:func:`platform.version()`
      - ``#1 SMP Fri Apr 25 13:07:35 EDT 2014``
        ``Java HotSpot(TM) 64-Bit Server VM, 25.51-b03, Oracle Corporation``
        ``Darwin Kernel Version 14.5.0: Wed Jul 29 02:18:53 PDT 2015; root:xnu-2782.40.9~2/RELEASE_X86_64``
    * - ``python_version``
      - ``'.'.join(platform.python_version_tuple()[:2])``
      - ``3.4``, ``2.7``
    * - ``python_full_version``
-     - ``platform.python_version()``
+     - :py:func:`platform.python_version()`
      - ``3.4.0``, ``3.5.0b1``
    * - ``implementation_name``
-     - ``sys.implementation.name``
+     - :py:data:`sys.implementation.name <sys.implementation>`
      - ``cpython``
    * - ``implementation_version``
      - see definition below
@@ -275,7 +275,7 @@ error like all other unknown variables.
      - ``test``
 
 The ``implementation_version`` marker variable is derived from
-``sys.implementation.version``:
+:py:data:`sys.implementation.version <sys.implementation>`:
 
 .. code-block:: python
 

source/specifications/entry-points.rst

@@ -18,10 +18,10 @@ example:
 
 The entry point file format was originally developed to allow packages built
 with setuptools to provide integration point metadata that would be read at
-runtime with ``importlib.metadata``. It is now defined as a PyPA interoperability
-specification in order to allow build tools other than setuptools to publish
-``importlib.metadata`` compatible entry point metadata, and runtime libraries other
-than ``importlib.metadata`` to portably read published entry point metadata
+runtime with :py:mod:`importlib.metadata`. It is now defined as a PyPA interoperability
+specification in order to allow build tools other than ``setuptools`` to publish
+:py:mod:`importlib.metadata` compatible entry point metadata, and runtime libraries other
+than :py:mod:`importlib.metadata` to portably read published entry point metadata
 (potentially with different caching and conflict resolution strategies).
 
 Data model
@@ -144,11 +144,11 @@ For instance, the entry point ``mycmd = mymod:main`` would create a command
 
 The difference between ``console_scripts`` and ``gui_scripts`` only affects
 Windows systems. ``console_scripts`` are wrapped in a console executable,
-so they are attached to a console and can use ``sys.stdin``, ``sys.stdout`` and
-``sys.stderr`` for input and output. ``gui_scripts`` are wrapped in a GUI
-executable, so they can be started without a console, but cannot use standard
-streams unless application code redirects them. Other platforms do not have the
-same distinction.
+so they are attached to a console and can use :py:data:`sys.stdin`,
+:py:data:`sys.stdout` and :py:data:`sys.stderr` for input and output.
+``gui_scripts`` are wrapped in a GUI executable, so they can be started without
+a console, but cannot use standard streams unless application code redirects them.
+Other platforms do not have the same distinction.
 
 Install tools are expected to set up wrappers for both ``console_scripts`` and
 ``gui_scripts`` in the scripts directory of the install scheme. They are not

source/specifications/name-normalization.rst

@@ -15,7 +15,7 @@ Name format
 A valid name consists only of ASCII letters and numbers, period,
 underscore and hyphen. It must start and end with a letter or number.
 This means that valid project names are limited to those which match the
-following regex (run with ``re.IGNORECASE``)::
+following regex (run with :py:data:`re.IGNORECASE`)::
 
     ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
 

source/specifications/platform-compatibility-tags.rst

@@ -45,7 +45,7 @@ a distribution.  Major implementations have abbreviated codes, initially:
 * pp: PyPy
 * jy: Jython
 
-Other Python implementations should use ``sys.implementation.name``.
+Other Python implementations should use :py:data:`sys.implementation.name <sys.implementation>`.
 
 The version is ``py_version_nodot``.  CPython gets away with no dot,
 but if one is needed the underscore ``_`` is used instead.  PyPy should
@@ -85,7 +85,7 @@ Platform Tag
 Basic platform tags
 -------------------
 
-In its simplest form, the platform tag is ``sysconfig.get_platform()`` with
+In its simplest form, the platform tag is :py:func:`sysconfig.get_platform()` with
 all hyphens ``-`` and periods ``.`` replaced with underscore ``_``.
 Until the removal of :ref:`distutils` in Python 3.12, this
 was ``distutils.util.get_platform()``. For example:
@@ -113,7 +113,7 @@ The current standard is the future-proof ``manylinux_x_y`` standard. It defines
 tags of the form ``manylinux_x_y_arch``, where ``x`` and ``y`` are glibc major
 and minor versions supported (e.g. ``manylinux_2_24_xxx`` should work on any
 distro using glibc 2.24+), and ``arch`` is the architecture, matching the value
-of ``sysconfig.get_platform()`` on the system as in the "simple" form above.
+of :py:func:`sysconfig.get_platform()` on the system as in the "simple" form above.
 
 The following older tags are still supported for backward compatibility:
 

source/specifications/recording-installed-packages.rst

@@ -114,7 +114,7 @@ On Windows, directories may be separated either by forward- or backslashes
 The *hash* is either an empty string or the name of a hash algorithm from
 :py:data:`hashlib.algorithms_guaranteed`, followed by the equals character ``=`` and
 the digest of the file's contents, encoded with the urlsafe-base64-nopad
-encoding (``base64.urlsafe_b64encode(digest)`` with trailing ``=`` removed).
+encoding (:py:func:`base64.urlsafe_b64encode(digest) <base64.urlsafe_b64encode()>` with trailing ``=`` removed).
 
 The *size* is either the empty string, or file's size in bytes,
 as a base 10 integer.

source/specifications/virtual-environments.rst

@@ -17,10 +17,10 @@ there was no previously standardised mechanism for declaring or discovering them
 Runtime detection of virtual environments
 =========================================
 
-At runtime, virtual environments can be identified by virtue of ``sys.prefix``
-(the filesystem location of the running interpreter) having a different value
-from ``sys.base_prefix`` (the default filesystem location of the standard library
-directories).
+At runtime, virtual environments can be identified by virtue of
+:py:data:`sys.prefix` (the filesystem location of the running interpreter)
+having a different value from :py:data:`sys.base_prefix` (the default filesystem
+location of the standard library directories).
 
 :ref:`venv-explanation` in the Python standard library documentation for the
 :py:mod:`venv` module covers this along with the concept of "activating" a
@@ -45,9 +45,9 @@ nesting is required or desired.
 
 Even in the absence of a ``pyvenv.cfg`` file, any approach (e.g.
 ``sitecustomize.py``, patching the installed Python runtime) that results in
-``sys.prefix`` and ``sys.base_prefix`` having different values, while still
-providing a matching default package installation scheme in ``sysconfig``, will
-be detected and behave as a Python virtual environment.
+:py:data:`sys.prefix` and :py:data:`sys.base_prefix` having different values,
+while still providing a matching default package installation scheme in
+:py:mod:`sysconfig`, will be detected and behave as a Python virtual environment.
 
 
 History