]> git.ipfire.org Git - thirdparty/Python/cpython.git/commitdiff
[3.12] gh-111151: Convert monospaced directives to :ref: (GH-111152) (#111269)
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Tue, 24 Oct 2023 15:30:21 +0000 (17:30 +0200)
committerGitHub <noreply@github.com>
Tue, 24 Oct 2023 15:30:21 +0000 (15:30 +0000)
gh-111151: Convert monospaced directives to :ref: (GH-111152)
(cherry picked from commit 1198076447f35b19a9173866ccb9839f3bcf3f17)

Co-authored-by: InSync <122007197+InSyncWithFoo@users.noreply.github.com>
Doc/library/asyncio-eventloop.rst
Doc/library/asyncio.rst
Doc/library/typing.rst

index f14fa5f18ce67f2673256e824af92d30644a38a2..0ff6136f1850925ca9845319b6dc4680400d9aa6 100644 (file)
@@ -661,6 +661,8 @@ Opening network connections
 Creating network servers
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
+.. _loop_create_server:
+
 .. coroutinemethod:: loop.create_server(protocol_factory, \
                         host=None, port=None, *, \
                         family=socket.AF_UNSPEC, \
@@ -1191,6 +1193,8 @@ Working with pipes
 Unix signals
 ^^^^^^^^^^^^
 
+.. _loop_add_signal_handler:
+
 .. method:: loop.add_signal_handler(signum, callback, *args)
 
    Set *callback* as the handler for the *signum* signal.
@@ -1419,6 +1423,8 @@ async/await code consider using the high-level
    :ref:`Subprocess Support on Windows <asyncio-windows-subprocess>` for
    details.
 
+.. _loop_subprocess_exec:
+
 .. coroutinemethod:: loop.subprocess_exec(protocol_factory, *args, \
                       stdin=subprocess.PIPE, stdout=subprocess.PIPE, \
                       stderr=subprocess.PIPE, **kwargs)
index c75ab47404c1e4ecb9c058c7bc00b4a20b9bf57a..5f33c6813e74c0bd0160ee5768bd23527a1b4dfd 100644 (file)
@@ -46,9 +46,9 @@ Additionally, there are **low-level** APIs for
 *library and framework developers* to:
 
 * create and manage :ref:`event loops <asyncio-event-loop>`, which
-  provide asynchronous APIs for :meth:`networking <loop.create_server>`,
-  running :meth:`subprocesses <loop.subprocess_exec>`,
-  handling :meth:`OS signals <loop.add_signal_handler>`, etc;
+  provide asynchronous APIs for :ref:`networking <loop_create_server>`,
+  running :ref:`subprocesses <loop_subprocess_exec>`,
+  handling :ref:`OS signals <loop_add_signal_handler>`, etc;
 
 * implement efficient protocols using
   :ref:`transports <asyncio-transports-protocols>`;
index 3eae7797925d779b5e9edade55a786fd795b440c..44665b63487b7205974d6b2aa68f8184c9cc2298 100644 (file)
@@ -304,7 +304,7 @@ a callable with any arbitrary parameter list would be acceptable:
    x = concat  # Also OK
 
 ``Callable`` cannot express complex signatures such as functions that take a
-variadic number of arguments, :func:`overloaded functions <overload>`, or
+variadic number of arguments, :ref:`overloaded functions <overload>`, or
 functions that have keyword-only parameters. However, these signatures can be
 expressed by defining a :class:`Protocol` class with a
 :meth:`~object.__call__` method:
@@ -526,7 +526,7 @@ A user-defined class can be defined as a generic class.
            self.logger.info('%s: %s', self.name, message)
 
 This syntax indicates that the class ``LoggedVar`` is parameterised around a
-single :class:`type variable <TypeVar>` ``T`` . This also makes ``T`` valid as
+single :ref:`type variable <typevar>` ``T`` . This also makes ``T`` valid as
 a type within the class body.
 
 Generic classes implicitly inherit from :class:`Generic`. For compatibility
@@ -1483,7 +1483,7 @@ These can be used as types in annotations. They all support subscription using
    Typing operator to conceptually mark an object as having been unpacked.
 
    For example, using the unpack operator ``*`` on a
-   :class:`type variable tuple <TypeVarTuple>` is equivalent to using ``Unpack``
+   :ref:`type variable tuple <typevartuple>` is equivalent to using ``Unpack``
    to mark the type variable tuple as having been unpacked::
 
       Ts = TypeVarTuple('Ts')
@@ -1574,6 +1574,8 @@ without the dedicated syntax, as documented below.
               ...
               # Etc.
 
+.. _typevar:
+
 .. class:: TypeVar(name, *constraints, bound=None, covariant=False, contravariant=False, infer_variance=False)
 
    Type variable.
@@ -1718,9 +1720,11 @@ without the dedicated syntax, as documented below.
       :ref:`type parameter <type-params>` syntax introduced by :pep:`695`.
       The ``infer_variance`` parameter was added.
 
+.. _typevartuple:
+
 .. class:: TypeVarTuple(name)
 
-   Type variable tuple. A specialized form of :class:`type variable <TypeVar>`
+   Type variable tuple. A specialized form of :ref:`type variable <typevar>`
    that enables *variadic* generics.
 
    Type variable tuples can be declared in :ref:`type parameter lists <type-params>`
@@ -1838,7 +1842,7 @@ without the dedicated syntax, as documented below.
 .. class:: ParamSpec(name, *, bound=None, covariant=False, contravariant=False)
 
    Parameter specification variable.  A specialized version of
-   :class:`type variables <TypeVar>`.
+   :ref:`type variables <typevar>`.
 
    In :ref:`type parameter lists <type-params>`, parameter specifications
    can be declared with two asterisks (``**``)::
@@ -2749,6 +2753,8 @@ Functions and decorators
 
    .. versionadded:: 3.11
 
+.. _overload:
+
 .. decorator:: overload
 
    Decorator for creating overloaded functions and methods.