Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-107298: Fix doc references to undocumented modules #107300

Merged
merged 2 commits into from
Jul 26, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Doc/c-api/arg.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
2 changes: 1 addition & 1 deletion Doc/c-api/codec.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
2 changes: 1 addition & 1 deletion Doc/c-api/typeobj.rst
Original file line number Diff line number Diff line change
Expand Up @@ -163,7 +163,7 @@

.. [#cols] Columns:

**"O"**: set on :c:type:`PyBaseObject_Type`

Check warning on line 166 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

c:type reference target not found: PyBaseObject_Type

**"T"**: set on :c:type:`PyType_Type`

Expand Down Expand Up @@ -484,7 +484,7 @@
PyObject Slots
--------------

The type object structure extends the :c:type:`PyVarObject` structure. The

Check warning on line 487 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:attr reference target not found: ob_size

Check warning on line 487 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:func reference target not found: type_new

Check warning on line 487 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:attr reference target not found: ob_size
:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
usually called from a class statement). Note that :c:data:`PyType_Type` (the
metatype) initializes :c:member:`~PyTypeObject.tp_itemsize`, which means that its instances (i.e.
Expand All @@ -493,7 +493,7 @@

.. c:member:: Py_ssize_t PyObject.ob_refcnt

This is the type object's reference count, initialized to ``1`` by the

Check warning on line 496 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:attr reference target not found: ob_type
``PyObject_HEAD_INIT`` macro. Note that for :ref:`statically allocated type
objects <static-types>`, the type's instances (objects whose :attr:`ob_type`
points back to the type) do *not* count as references. But for
Expand All @@ -518,7 +518,7 @@

Foo_Type.ob_type = &PyType_Type;

This should be done before any instances of the type are created.

Check warning on line 521 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:attr reference target not found: ob_type

Check warning on line 521 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:attr reference target not found: ob_type
:c:func:`PyType_Ready` checks if :attr:`ob_type` is ``NULL``, and if so,
initializes it to the :attr:`ob_type` field of the base class.
:c:func:`PyType_Ready` will not change this field if it is non-zero.
Expand All @@ -540,7 +540,7 @@
allocated objects <heap-types>`, these two fields are used to link the
object into a doubly linked list of *all* live objects on the heap.

This could be used for various debugging purposes; currently the only uses

Check warning on line 543 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:func reference target not found: sys.getobjects
are the :func:`sys.getobjects` function and to print the objects that are
still alive at the end of a run when the environment variable
:envvar:`PYTHONDUMPREFS` is set.
Expand All @@ -567,19 +567,19 @@
PyTypeObject Slots
------------------

Each slot has a section describing inheritance. If :c:func:`PyType_Ready`

Check warning on line 570 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

c:type reference target not found: PyBaseObject_Type
may set a value when the field is set to ``NULL`` then there will also be
a "Default" section. (Note that many fields set on :c:type:`PyBaseObject_Type`
and :c:type:`PyType_Type` effectively act as defaults.)

.. c:member:: const char* PyTypeObject.tp_name

Pointer to a NUL-terminated string containing the name of the type. For types

Check warning on line 577 in Doc/c-api/typeobj.rst

View workflow job for this annotation

GitHub Actions / Docs / Docs

py:class reference target not found: T
that are accessible as module globals, the string should be the full module
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>`,
Expand Down
2 changes: 1 addition & 1 deletion Doc/c-api/unicode.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
4 changes: 2 additions & 2 deletions Doc/extending/extending.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down
8 changes: 4 additions & 4 deletions Doc/extending/newtypes_tutorial.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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*
Expand All @@ -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::
Expand Down Expand Up @@ -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. ::
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion Doc/install/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 0 additions & 2 deletions Doc/tools/.nitignore
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading