python
diff --git a/‎Doc/c-api/module.rst
Lines changed: 2 additions & 2 deletions b/‎Doc/c-api/module.rst
Lines changed: 2 additions & 2 deletions
diff --git a/‎Doc/c-api/set.rst
Lines changed: 1 addition & 1 deletion b/‎Doc/c-api/set.rst
Lines changed: 1 addition & 1 deletion
diff --git a/‎Doc/c-api/structures.rst
Lines changed: 1 addition & 1 deletion b/‎Doc/c-api/structures.rst
Lines changed: 1 addition & 1 deletion
diff --git a/‎Doc/c-api/sys.rst
Lines changed: 1 addition & 1 deletion b/‎Doc/c-api/sys.rst
Lines changed: 1 addition & 1 deletion
diff --git a/‎Doc/c-api/typeobj.rst
Lines changed: 1 addition & 1 deletion b/‎Doc/c-api/typeobj.rst
Lines changed: 1 addition & 1 deletion
diff --git a/‎Doc/extending/extending.rst
Lines changed: 10 additions & 10 deletions b/‎Doc/extending/extending.rst
Lines changed: 10 additions & 10 deletions
diff --git a/‎Doc/extending/newtypes_tutorial.rst
Lines changed: 22 additions & 22 deletions b/‎Doc/extending/newtypes_tutorial.rst
Lines changed: 22 additions & 22 deletions
@@ -282,7 +282,7 @@ An alternate way to specify extensions is to request "multi-phase initialization
 Extension modules created this way behave more like Python modules: the
 initialization is split between the *creation phase*, when the module object
 is created, and the *execution phase*, when it is populated.
-The distinction is similar to the :py:meth:`__new__` and :py:meth:`__init__` methods
+The distinction is similar to the :py:meth:`!__new__` and :py:meth:`!__init__` methods
 of classes.
 
 Unlike modules created using single-phase initialization, these modules are not
@@ -293,7 +293,7 @@ By default, multiple modules created from the same definition should be
 independent: changes to one should not affect the others.
 This means that all state should be specific to the module object (using e.g.
 using :c:func:`PyModule_GetState`), or its contents (such as the module's
-:attr:`__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
+:attr:`~object.__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
 
 All modules created using multi-phase initialization are expected to support
 :ref:`sub-interpreters <sub-interpreter-support>`. Making sure multiple modules
 
@@ -122,7 +122,7 @@ or :class:`frozenset` or instances of their subtypes.
 .. c:function:: int PySet_Contains(PyObject *anyset, PyObject *key)
 
    Return ``1`` if found, ``0`` if not found, and ``-1`` if an error is encountered.  Unlike
-   the Python :meth:`__contains__` method, this function does not automatically
+   the Python :meth:`~object.__contains__` method, this function does not automatically
    convert unhashable sets into temporary frozensets.  Raise a :exc:`TypeError` if
    the *key* is unhashable. Raise :exc:`PyExc_SystemError` if *anyset* is not a
    :class:`set`, :class:`frozenset`, or an instance of a subtype.
 
@@ -393,7 +393,7 @@ definition with the same method name.
    *METH_COEXIST*, the default is to skip repeated definitions.  Since slot
    wrappers are loaded before the method table, the existence of a
    *sq_contains* slot, for example, would generate a wrapped method named
-   :meth:`__contains__` and preclude the loading of a corresponding
+   :meth:`~object.__contains__` and preclude the loading of a corresponding
    PyCFunction with the same name.  With the flag defined, the PyCFunction
    will be loaded in place of the wrapper object and will co-exist with the
    slot.  This is helpful because calls to PyCFunctions are optimized more
 
@@ -363,7 +363,7 @@ Process Control
    This function should only be invoked when a condition is detected that would
    make it dangerous to continue using the Python interpreter; e.g., when the
    object administration appears to be corrupted.  On Unix, the standard C library
-   function :c:func:`abort` is called which will attempt to produce a :file:`core`
+   function :c:func:`!abort` is called which will attempt to produce a :file:`core`
    file.
 
    The ``Py_FatalError()`` function is replaced with a macro which logs
 
@@ -579,7 +579,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
    name, followed by a dot, followed by the type name; for built-in types, it
    should be just the type name.  If the module is a submodule of a package, the
    full package name is part of the full module name.  For example, a type named
-   :class:`T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P`
+   :class:`!T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P`
    should have the :c:member:`~PyTypeObject.tp_name` initializer ``"P.Q.M.T"``.
 
    For :ref:`dynamically allocated type objects <heap-types>`,
 
@@ -230,7 +230,7 @@ with an exception object::
        return m;
    }
 
-Note that the Python name for the exception object is :exc:`spam.error`.  The
+Note that the Python name for the exception object is :exc:`!spam.error`.  The
 :c:func:`PyErr_NewException` function may create a class with the base class
 being :exc:`Exception` (unless another class is passed in instead of ``NULL``),
 described in :ref:`bltin-exceptions`.
@@ -245,7 +245,7 @@ raises the exception could cause a core dump or other unintended side effects.
 We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in this
 sample.
 
-The :exc:`spam.error` exception can be raised in your extension module using a
+The :exc:`!spam.error` exception can be raised in your extension module using a
 call to :c:func:`PyErr_SetString` as shown below::
 
    static PyObject *
@@ -315,7 +315,7 @@ contexts, as we have seen.
 The Module's Method Table and Initialization Function
 =====================================================
 
-I promised to show how :c:func:`spam_system` is called from Python programs.
+I promised to show how :c:func:`!spam_system` is called from Python programs.
 First, we need to list its name and address in a "method table"::
 
    static PyMethodDef SpamMethods[] = {
@@ -1041,13 +1041,13 @@ Let's follow the control flow into :c:func:`PyList_SetItem`.  The list owns
 references to all its items, so when item 1 is replaced, it has to dispose of
 the original item 1.  Now let's suppose the original item 1 was an instance of a
 user-defined class, and let's further suppose that the class defined a
-:meth:`__del__` method.  If this class instance has a reference count of 1,
-disposing of it will call its :meth:`__del__` method.
+:meth:`!__del__` method.  If this class instance has a reference count of 1,
+disposing of it will call its :meth:`!__del__` method.
 
-Since it is written in Python, the :meth:`__del__` method can execute arbitrary
+Since it is written in Python, the :meth:`!__del__` method can execute arbitrary
 Python code.  Could it perhaps do something to invalidate the reference to
-``item`` in :c:func:`bug`?  You bet!  Assuming that the list passed into
-:c:func:`bug` is accessible to the :meth:`__del__` method, it could execute a
+``item`` in :c:func:`!bug`?  You bet!  Assuming that the list passed into
+:c:func:`!bug` is accessible to the :meth:`!__del__` method, it could execute a
 statement to the effect of ``del list[0]``, and assuming this was the last
 reference to that object, it would free the memory associated with it, thereby
 invalidating ``item``.
@@ -1068,7 +1068,7 @@ increment the reference count.  The correct version of the function reads::
 
 This is a true story.  An older version of Python contained variants of this bug
 and someone spent a considerable amount of time in a C debugger to figure out
-why his :meth:`__del__` methods would fail...
+why his :meth:`!__del__` methods would fail...
 
 The second case of problems with a borrowed reference is a variant involving
 threads.  Normally, multiple threads in the Python interpreter can't get in each
@@ -1235,7 +1235,7 @@ The function :c:func:`PySpam_System` is a plain C function, declared
        return system(command);
    }
 
-The function :c:func:`spam_system` is modified in a trivial way::
+The function :c:func:`!spam_system` is modified in a trivial way::
 
    static PyObject *
    spam_system(PyObject *self, PyObject *args)
 
@@ -36,7 +36,7 @@ So, if you want to define a new extension type, you need to create a new type
 object.
 
 This sort of thing can only be explained by example, so here's a minimal, but
-complete, module that defines a new type named :class:`Custom` inside a C
+complete, module that defines a new type named :class:`!Custom` inside a C
 extension module :mod:`!custom`:
 
 .. note::
@@ -50,9 +50,9 @@ extension module :mod:`!custom`:
 Now that's quite a bit to take in at once, but hopefully bits will seem familiar
 from the previous chapter.  This file defines three things:
 
-#. What a :class:`Custom` **object** contains: this is the ``CustomObject``
-   struct, which is allocated once for each :class:`Custom` instance.
-#. How the :class:`Custom` **type** behaves: this is the ``CustomType`` struct,
+#. What a :class:`!Custom` **object** contains: this is the ``CustomObject``
+   struct, which is allocated once for each :class:`!Custom` instance.
+#. How the :class:`!Custom` **type** behaves: this is the ``CustomType`` struct,
    which defines a set of flags and function pointers that the interpreter
    inspects when specific operations are requested.
 #. How to initialize the :mod:`!custom` module: this is the ``PyInit_custom``
@@ -128,15 +128,15 @@ our objects and in some error messages, for example:
 
 Note that the name is a dotted name that includes both the module name and the
 name of the type within the module. The module in this case is :mod:`!custom` and
-the type is :class:`Custom`, so we set the type name to :class:`custom.Custom`.
+the type is :class:`!Custom`, so we set the type name to :class:`custom.Custom`.
 Using the real dotted import path is important to make your type compatible
 with the :mod:`pydoc` and :mod:`pickle` modules. ::
 
    .tp_basicsize = sizeof(CustomObject),
    .tp_itemsize = 0,
 
 This is so that Python knows how much memory to allocate when creating
-new :class:`Custom` instances.  :c:member:`~PyTypeObject.tp_itemsize` is
+new :class:`!Custom` instances.  :c:member:`~PyTypeObject.tp_itemsize` is
 only used for variable-sized objects and should otherwise be zero.
 
 .. note::
@@ -176,7 +176,7 @@ Everything else in the file should be familiar, except for some code in
    if (PyType_Ready(&CustomType) < 0)
        return;
 
-This initializes the :class:`Custom` type, filling in a number of members
+This initializes the :class:`!Custom` type, filling in a number of members
 to the appropriate default values, including :attr:`ob_type` that we initially
 set to ``NULL``. ::
 
@@ -186,7 +186,7 @@ set to ``NULL``. ::
    }
 
 This adds the type to the module dictionary.  This allows us to create
-:class:`Custom` instances by calling the :class:`Custom` class:
+:class:`!Custom` instances by calling the :class:`!Custom` class:
 
 .. code-block:: pycon
 
@@ -237,7 +237,7 @@ adds these capabilities:
 
 This version of the module has a number of changes.
 
-The  :class:`Custom` type now has three data attributes in its C struct,
+The  :class:`!Custom` type now has three data attributes in its C struct,
 *first*, *last*, and *number*.  The *first* and *last* variables are Python
 strings containing first and last names.  The *number* attribute is a C integer.
 
@@ -312,7 +312,7 @@ The ``tp_new`` handler is responsible for creating (as opposed to initializing)
 objects of the type.  It is exposed in Python as the :meth:`__new__` method.
 It is not required to define a ``tp_new`` member, and indeed many extension
 types will simply reuse :c:func:`PyType_GenericNew` as done in the first
-version of the ``Custom`` type above.  In this case, we use the ``tp_new``
+version of the :class:`!Custom` type above.  In this case, we use the ``tp_new``
 handler to initialize the ``first`` and ``last`` attributes to non-``NULL``
 default values.
 
@@ -468,8 +468,8 @@ concatenation of the first and last names. ::
        return PyUnicode_FromFormat("%S %S", self->first, self->last);
    }
 
-The method is implemented as a C function that takes a :class:`Custom` (or
-:class:`Custom` subclass) instance as the first argument.  Methods always take an
+The method is implemented as a C function that takes a :class:`!Custom` (or
+:class:`!Custom` subclass) instance as the first argument.  Methods always take an
 instance as the first argument. Methods often take positional and keyword
 arguments as well, but in this case we don't take any and don't need to accept
 a positional argument tuple or keyword argument dictionary. This method is
@@ -530,7 +530,7 @@ Providing finer control over data attributes
 ============================================
 
 In this section, we'll provide finer control over how the :attr:`first` and
-:attr:`last` attributes are set in the :class:`Custom` example. In the previous
+:attr:`last` attributes are set in the :class:`!Custom` example. In the previous
 version of our module, the instance variables :attr:`first` and :attr:`last`
 could be set to non-string values or even deleted. We want to make sure that
 these attributes always contain strings.
@@ -569,13 +569,13 @@ getting and setting the :attr:`first` attribute::
        return 0;
    }
 
-The getter function is passed a :class:`Custom` object and a "closure", which is
+The getter function is passed a :class:`!Custom` object and a "closure", which is
 a void pointer.  In this case, the closure is ignored.  (The closure supports an
 advanced usage in which definition data is passed to the getter and setter. This
 could, for example, be used to allow a single set of getter and setter functions
 that decide the attribute to get or set based on data in the closure.)
 
-The setter function is passed the :class:`Custom` object, the new value, and the
+The setter function is passed the :class:`!Custom` object, the new value, and the
 closure.  The new value may be ``NULL``, in which case the attribute is being
 deleted.  In our setter, we raise an error if the attribute is deleted or if its
 new value is not a string.
@@ -664,11 +664,11 @@ still has a reference from itself. Its reference count doesn't drop to zero.
 Fortunately, Python's cyclic garbage collector will eventually figure out that
 
-In the second version of the :class:`Custom` example, we allowed any kind of
+In the second version of the :class:`!Custom` example, we allowed any kind of
 object to be stored in the :attr:`first` or :attr:`last` attributes [#]_.
 Besides, in the second and third versions, we allowed subclassing
-:class:`Custom`, and subclasses may add arbitrary attributes.  For any of
-those two reasons, :class:`Custom` objects can participate in cycles:
+:class:`!Custom`, and subclasses may add arbitrary attributes.  For any of
+those two reasons, :class:`!Custom` objects can participate in cycles:
 
 .. code-block:: pycon
 
@@ -678,8 +678,8 @@ those two reasons, :class:`Custom` objects can participate in cycles:
    >>> n = Derived()
    >>> n.some_attribute = n
 
-To allow a :class:`Custom` instance participating in a reference cycle to
-be properly detected and collected by the cyclic GC, our :class:`Custom` type
+To allow a :class:`!Custom` instance participating in a reference cycle to
+be properly detected and collected by the cyclic GC, our :class:`!Custom` type
 needs to fill two additional slots and to enable a flag that enables these slots:
 
 .. literalinclude:: ../includes/custom4.c
@@ -809,7 +809,7 @@ increases an internal counter:
 .. literalinclude:: ../includes/sublist.c
 
 
-As you can see, the source code closely resembles the :class:`Custom` examples in
+As you can see, the source code closely resembles the :class:`!Custom` examples in
 previous sections. We will break down the main differences between them. ::
 
    typedef struct {
@@ -875,7 +875,7 @@ slot with :c:func:`PyType_GenericNew` -- the allocation function from the base
 type will be inherited.
 
 After that, calling :c:func:`PyType_Ready` and adding the type object to the
-module is the same as with the basic :class:`Custom` examples.
+module is the same as with the basic :class:`!Custom` examples.
 
 
 .. rubric:: Footnotes