From 5b6856ba8d0eff3c848bc809cd41f77a1472e9ed Mon Sep 17 00:00:00 2001 From: Christian Zinck Date: Mon, 8 Jun 2026 06:24:26 -0400 Subject: [PATCH 1/2] gh-101100: Fix Sphinx warnings in 'Buffer Object Structures' documentation (GH-151058) (cherry picked from commit a1873300eebe9c634f59592c3333035768f09de9) Co-authored-by: Christian Zinck --- Doc/c-api/typeobj.rst | 10 +++++----- Doc/tools/.nitignore | 1 - 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst index f22201dc399333b..18bbd016cb22abd 100644 --- a/Doc/c-api/typeobj.rst +++ b/Doc/c-api/typeobj.rst @@ -2745,13 +2745,13 @@ Buffer Object Structures steps: (1) Check if the request can be met. If not, raise :exc:`BufferError`, - set :c:expr:`view->obj` to ``NULL`` and return ``-1``. + set ``view->obj`` to ``NULL`` and return ``-1``. (2) Fill in the requested fields. (3) Increment an internal counter for the number of exports. - (4) Set :c:expr:`view->obj` to *exporter* and increment :c:expr:`view->obj`. + (4) Set ``view->obj`` to *exporter* and increment ``view->obj``. (5) Return ``0``. @@ -2759,10 +2759,10 @@ Buffer Object Structures schemes can be used: * Re-export: Each member of the tree acts as the exporting object and - sets :c:expr:`view->obj` to a new reference to itself. + sets ``view->obj`` to a new reference to itself. * Redirect: The buffer request is redirected to the root object of the - tree. Here, :c:expr:`view->obj` will be a new reference to the root + tree. Here, ``view->obj`` will be a new reference to the root object. The individual fields of *view* are described in section @@ -2806,7 +2806,7 @@ Buffer Object Structures *view* argument. - This function MUST NOT decrement :c:expr:`view->obj`, since that is + This function MUST NOT decrement ``view->obj``, since that is done automatically in :c:func:`PyBuffer_Release` (this scheme is useful for breaking reference cycles). diff --git a/Doc/tools/.nitignore b/Doc/tools/.nitignore index 39b88f88a61b7c5..c863c99e6dca0c7 100644 --- a/Doc/tools/.nitignore +++ b/Doc/tools/.nitignore @@ -8,7 +8,6 @@ Doc/c-api/init_config.rst Doc/c-api/intro.rst Doc/c-api/module.rst Doc/c-api/stable.rst -Doc/c-api/typeobj.rst Doc/library/ast.rst Doc/library/asyncio-extending.rst Doc/library/asyncio-policy.rst From 8283ca5b12fb34d30777b61cd7b39895b3e82ede Mon Sep 17 00:00:00 2001 From: Stan Ulbrych Date: Mon, 8 Jun 2026 11:43:06 +0100 Subject: [PATCH 2/2] Drop ref to non-existent `PyLong_Export` --- Doc/c-api/typeobj.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst index 18bbd016cb22abd..561f95cb90a1778 100644 --- a/Doc/c-api/typeobj.rst +++ b/Doc/c-api/typeobj.rst @@ -611,9 +611,7 @@ and :c:data:`PyType_Type` effectively act as defaults.) argument, and store in the instance's :c:member:`~PyVarObject.ob_size` field. Note that the :c:member:`~PyVarObject.ob_size` field may later be used for other purposes. For example, :py:type:`int` instances use the bits of - :c:member:`~PyVarObject.ob_size` in an implementation-defined - way; the underlying storage and its size should be accessed using - :c:func:`PyLong_Export`. + :c:member:`~PyVarObject.ob_size` in an implementation-defined way. .. note::