mirror of
https://github.com/python/cpython.git
synced 2024-11-24 02:15:30 +08:00
gh-107298: Fix doc references to undocumented modules (#107300)
Update also Doc/tools/.nitignore.
This commit is contained in:
parent
b1de3807b8
commit
87b39028e5
@ -477,7 +477,7 @@ API Functions
|
||||
will be set if there was a failure.
|
||||
|
||||
This is an example of the use of this function, taken from the sources for the
|
||||
:mod:`_weakref` helper module for weak references::
|
||||
:mod:`!_weakref` helper module for weak references::
|
||||
|
||||
static PyObject *
|
||||
weakref_ref(PyObject *self, PyObject *args)
|
||||
|
@ -7,7 +7,7 @@ Codec registry and support functions
|
||||
|
||||
Register a new codec search function.
|
||||
|
||||
As side effect, this tries to load the :mod:`encodings` package, if not yet
|
||||
As side effect, this tries to load the :mod:`!encodings` package, if not yet
|
||||
done, to make sure that it is always first in the list of search functions.
|
||||
|
||||
.. c:function:: int PyCodec_Unregister(PyObject *search_function)
|
||||
|
@ -579,7 +579,7 @@ and :c:type:`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>`,
|
||||
|
@ -1205,7 +1205,7 @@ Character Map Codecs
|
||||
|
||||
This codec is special in that it can be used to implement many different codecs
|
||||
(and this is in fact what was done to obtain most of the standard codecs
|
||||
included in the :mod:`encodings` package). The codec uses mappings to encode and
|
||||
included in the :mod:`!encodings` package). The codec uses mappings to encode and
|
||||
decode characters. The mapping objects provided must support the
|
||||
:meth:`__getitem__` mapping interface; dictionaries and sequences work well.
|
||||
|
||||
|
@ -367,7 +367,7 @@ Note that PyMODINIT_FUNC declares the function as ``PyObject *`` return type,
|
||||
declares any special linkage declarations required by the platform, and for C++
|
||||
declares the function as ``extern "C"``.
|
||||
|
||||
When the Python program imports module :mod:`spam` for the first time,
|
||||
When the Python program imports module :mod:`!spam` for the first time,
|
||||
:c:func:`PyInit_spam` is called. (See below for comments about embedding Python.)
|
||||
It calls :c:func:`PyModule_Create`, which returns a module object, and
|
||||
inserts built-in function objects into the newly created module based upon the
|
||||
@ -1219,7 +1219,7 @@ file corresponding to the module provides a macro that takes care of importing
|
||||
the module and retrieving its C API pointers; client modules only have to call
|
||||
this macro before accessing the C API.
|
||||
|
||||
The exporting module is a modification of the :mod:`spam` module from section
|
||||
The exporting module is a modification of the :mod:`!spam` module from section
|
||||
:ref:`extending-simpleexample`. The function :func:`spam.system` does not call
|
||||
the C library function :c:func:`system` directly, but a function
|
||||
:c:func:`PySpam_System`, which would of course do something more complicated in
|
||||
|
@ -37,7 +37,7 @@ 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
|
||||
extension module :mod:`custom`:
|
||||
extension module :mod:`!custom`:
|
||||
|
||||
.. note::
|
||||
What we're showing here is the traditional way of defining *static*
|
||||
@ -55,7 +55,7 @@ from the previous chapter. This file defines three things:
|
||||
#. 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``
|
||||
#. How to initialize the :mod:`!custom` module: this is the ``PyInit_custom``
|
||||
function and the associated ``custommodule`` struct.
|
||||
|
||||
The first bit is::
|
||||
@ -127,7 +127,7 @@ our objects and in some error messages, for example:
|
||||
TypeError: can only concatenate str (not "custom.Custom") to str
|
||||
|
||||
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
|
||||
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`.
|
||||
Using the real dotted import path is important to make your type compatible
|
||||
with the :mod:`pydoc` and :mod:`pickle` modules. ::
|
||||
@ -229,7 +229,7 @@ Adding data and methods to the Basic example
|
||||
============================================
|
||||
|
||||
Let's extend the basic example to add some data and methods. Let's also make
|
||||
the type usable as a base class. We'll create a new module, :mod:`custom2` that
|
||||
the type usable as a base class. We'll create a new module, :mod:`!custom2` that
|
||||
adds these capabilities:
|
||||
|
||||
.. literalinclude:: ../includes/custom2.c
|
||||
|
@ -374,7 +374,7 @@ will expand this to your home directory::
|
||||
|
||||
To make Python find the distributions installed with this scheme, you may have
|
||||
to :ref:`modify Python's search path <inst-search-path>` or edit
|
||||
:mod:`sitecustomize` (see :mod:`site`) to call :func:`site.addsitedir` or edit
|
||||
:mod:`!sitecustomize` (see :mod:`site`) to call :func:`site.addsitedir` or edit
|
||||
:data:`sys.path`.
|
||||
|
||||
The :option:`!--home` option defines the installation base directory. Files are
|
||||
|
@ -4,14 +4,12 @@
|
||||
|
||||
Doc/c-api/allocation.rst
|
||||
Doc/c-api/apiabiversion.rst
|
||||
Doc/c-api/arg.rst
|
||||
Doc/c-api/bool.rst
|
||||
Doc/c-api/buffer.rst
|
||||
Doc/c-api/bytes.rst
|
||||
Doc/c-api/capsule.rst
|
||||
Doc/c-api/cell.rst
|
||||
Doc/c-api/code.rst
|
||||
Doc/c-api/codec.rst
|
||||
Doc/c-api/complex.rst
|
||||
Doc/c-api/conversion.rst
|
||||
Doc/c-api/datetime.rst
|
||||
|
Loading…
Reference in New Issue
Block a user