Docs: module pages should not link to themselves

Author: nedbat

Doc/library/__future__.rst

@@ -15,25 +15,25 @@ before the release in which the feature becomes standard.
 
 While these future statements are given additional special meaning by the
 Python compiler, they are still executed like any other import statement and
-the :mod:`__future__` exists and is handled by the import system the same way
+the :mod:`!__future__` exists and is handled by the import system the same way
 any other Python module would be. This design serves three purposes:
 
 * To avoid confusing existing tools that analyze import statements and expect to
   find the modules they're importing.
 
 * To document when incompatible changes were introduced, and when they will be
   --- or were --- made mandatory.  This is a form of executable documentation, and
-  can be inspected programmatically via importing :mod:`__future__` and examining
+  can be inspected programmatically via importing :mod:`!__future__` and examining
   its contents.
 
 * To ensure that :ref:`future statements <future>` run under releases prior to
-  Python 2.1 at least yield runtime exceptions (the import of :mod:`__future__`
+  Python 2.1 at least yield runtime exceptions (the import of :mod:`!__future__`
   will fail, because there was no module of that name prior to 2.1).
 
 Module Contents
 ---------------
 
-No feature description will ever be deleted from :mod:`__future__`. Since its
+No feature description will ever be deleted from :mod:`!__future__`. Since its
 introduction in Python 2.1 the following features have found their way into the
 language using this mechanism:
 

Doc/library/argparse.rst

@@ -13,7 +13,7 @@
 
 .. note::
 
-   While :mod:`argparse` is the default recommended standard library module
+   While :mod:`!argparse` is the default recommended standard library module
    for implementing basic command line applications, authors with more
    exacting requirements for exactly how their command line applications
    behave may find it doesn't provide the necessary level of control.

Doc/library/ast.rst

@@ -15,7 +15,7 @@
 
 --------------
 
-The :mod:`ast` module helps Python applications to process trees of the Python
+The :mod:`!ast` module helps Python applications to process trees of the Python
 abstract syntax grammar.  The abstract syntax itself might change with each
 Python release; this module helps to find out programmatically what the current
 grammar looks like.
@@ -46,7 +46,7 @@ Node classes
    This is the base of all AST node classes.  The actual node classes are
    derived from the :file:`Parser/Python.asdl` file, which is reproduced
    :ref:`above <abstract-grammar>`.  They are defined in the :mod:`!_ast` C
-   module and re-exported in :mod:`ast`.
+   module and re-exported in :mod:`!ast`.
 
    There is one class defined for each left-hand side symbol in the abstract
    grammar (for example, :class:`ast.stmt` or :class:`ast.expr`).  In addition,
@@ -2200,10 +2200,10 @@ Async and await
    occurrences of the same value (for example, :class:`ast.Add`).
 
 
-:mod:`ast` helpers
+:mod:`!ast` helpers
 ------------------
 
-Apart from the node classes, the :mod:`ast` module defines these utility functions
+Apart from the node classes, the :mod:`!ast` module defines these utility functions
 and classes for traversing abstract syntax trees:
 
 .. function:: parse(source, filename='<unknown>', mode='exec', *, type_comments=False, feature_version=None, optimize=-1, module=None)
@@ -2576,7 +2576,7 @@ Command-line usage
 
 .. versionadded:: 3.9
 
-The :mod:`ast` module can be executed as a script from the command line.
+The :mod:`!ast` module can be executed as a script from the command line.
 It is as simple as:
 
 .. code-block:: sh

Doc/library/atexit.rst

@@ -9,9 +9,9 @@
 
 --------------
 
-The :mod:`atexit` module defines functions to register and unregister cleanup
+The :mod:`!atexit` module defines functions to register and unregister cleanup
 functions.  Functions thus registered are automatically executed upon normal
-interpreter termination.  :mod:`atexit` runs these functions in the *reverse*
+interpreter termination.  :mod:`!atexit` runs these functions in the *reverse*
 order in which they were registered; if you register ``A``, ``B``, and ``C``,
 at interpreter termination time they will be run in the order ``C``, ``B``,
 ``A``.
@@ -64,21 +64,21 @@ a cleanup function is undefined.
    Remove *func* from the list of functions to be run at interpreter shutdown.
    :func:`unregister` silently does nothing if *func* was not previously
    registered.  If *func* has been registered more than once, every occurrence
-   of that function in the :mod:`atexit` call stack will be removed.  Equality
+   of that function in the :mod:`!atexit` call stack will be removed.  Equality
    comparisons (``==``) are used internally during unregistration, so function
    references do not need to have matching identities.
 
 
 .. seealso::
 
    Module :mod:`readline`
-      Useful example of :mod:`atexit` to read and write :mod:`readline` history
+      Useful example of :mod:`!atexit` to read and write :mod:`readline` history
       files.
 
 
 .. _atexit-example:
 
-:mod:`atexit` Example
+:mod:`!atexit` Example
 ---------------------
 
 The following simple example demonstrates how a module can initialize a counter

Doc/library/bdb.rst

@@ -8,7 +8,7 @@
 
 --------------
 
-The :mod:`bdb` module handles basic debugger functions, like setting breakpoints
+The :mod:`!bdb` module handles basic debugger functions, like setting breakpoints
 or managing execution via the debugger.
 
 The following exception is defined:
@@ -18,7 +18,7 @@ The following exception is defined:
    Exception raised by the :class:`Bdb` class for quitting the debugger.
 
 
-The :mod:`bdb` module also defines two classes:
+The :mod:`!bdb` module also defines two classes:
 
 .. class:: Breakpoint(self, file, line, temporary=False, cond=None, funcname=None)
 

Doc/library/binascii.rst

@@ -10,10 +10,10 @@
 
 --------------
 
-The :mod:`binascii` module contains a number of methods to convert between
+The :mod:`!binascii` module contains a number of methods to convert between
 binary and various ASCII-encoded binary representations. Normally, you will not
 use these functions directly but use wrapper modules like
-:mod:`base64` instead. The :mod:`binascii` module contains
+:mod:`base64` instead. The :mod:`!binascii` module contains
 low-level functions written in C for greater speed that are used by the
 higher-level modules.
 
@@ -28,7 +28,7 @@ higher-level modules.
       ASCII-only unicode strings are now accepted by the ``a2b_*`` functions.
 
 
-The :mod:`binascii` module defines the following functions:
+The :mod:`!binascii` module defines the following functions:
 
 
 .. function:: a2b_uu(string)

Doc/library/bisect.rst

@@ -16,7 +16,7 @@ having to sort the list after each insertion.  For long lists of items with
 expensive comparison operations, this can be an improvement over
 linear searches or frequent resorting.
 
-The module is called :mod:`bisect` because it uses a basic bisection
+The module is called :mod:`!bisect` because it uses a basic bisection
 algorithm to do its work.  Unlike other bisection tools that search for a
 specific value, the functions in this module are designed to locate an
 insertion point. Accordingly, the functions never call an :meth:`~object.__eq__`
@@ -27,9 +27,9 @@ point between values in an array.
 .. note::
 
    The functions in this module are not thread-safe. If multiple threads
-   concurrently use :mod:`bisect` functions on the same sequence, this
+   concurrently use :mod:`!bisect` functions on the same sequence, this
    may result in undefined behaviour. Likewise, if the provided sequence
-   is mutated by a different thread while a :mod:`bisect` function
+   is mutated by a different thread while a :mod:`!bisect` function
    is operating on it, the result is undefined. For example, using
    :py:func:`~bisect.insort_left` on the same list from multiple threads
    may result in the list becoming unsorted.

Doc/library/bz2.rst

@@ -16,7 +16,7 @@
 This module provides a comprehensive interface for compressing and
 decompressing data using the bzip2 compression algorithm.
 
-The :mod:`bz2` module contains:
+The :mod:`!bz2` module contains:
 
 * The :func:`.open` function and :class:`BZ2File` class for reading and
   writing compressed files.
@@ -317,7 +317,7 @@ One-shot (de)compression
 Examples of usage
 -----------------
 
-Below are some examples of typical usage of the :mod:`bz2` module.
+Below are some examples of typical usage of the :mod:`!bz2` module.
 
 Using :func:`compress` and :func:`decompress` to demonstrate round-trip compression:
 

Doc/library/calendar.rst

@@ -452,7 +452,7 @@ For simple text calendars this module provides the following functions.
    inverse.
 
 
-The :mod:`calendar` module exports the following data attributes:
+The :mod:`!calendar` module exports the following data attributes:
 
 .. data:: day_name
 
@@ -578,7 +578,7 @@ The :mod:`calendar` module exports the following data attributes:
    .. versionadded:: 3.12
 
 
-The :mod:`calendar` module defines the following exceptions:
+The :mod:`!calendar` module defines the following exceptions:
 
 .. exception:: IllegalMonthError(month)
 
@@ -617,7 +617,7 @@ Command-line usage
 
 .. versionadded:: 2.5
 
-The :mod:`calendar` module can be executed as a script from the command line
+The :mod:`!calendar` module can be executed as a script from the command line
 to interactively print a calendar.
 
 .. code-block:: shell

Doc/library/cmath.rst

@@ -124,7 +124,7 @@ rectangular coordinates to polar coordinates and back.
 
    The modulus (absolute value) of a complex number *z* can be
    computed using the built-in :func:`abs` function.  There is no
-   separate :mod:`cmath` module function for this operation.
+   separate :mod:`!cmath` module function for this operation.
 
 
 .. function:: polar(z)
@@ -357,7 +357,7 @@ Note that the selection of functions is similar, but not identical, to that in
 module :mod:`math`.  The reason for having two modules is that some users aren't
 interested in complex numbers, and perhaps don't even know what they are.  They
 would rather have ``math.sqrt(-1)`` raise an exception than return a complex
-number. Also note that the functions defined in :mod:`cmath` always return a
+number. Also note that the functions defined in :mod:`!cmath` always return a
 complex number, even if the answer can be expressed as a real number (in which
 case the complex number has an imaginary part of zero).