8000 [3.11] gh-93738: Documentation C syntax (Function glob patterns -> li… · python/cpython@6ff98f7 · GitHub
[go: up one dir, main page]
Skip to content

Commit 6ff98f7

Browse files
miss-islingtonAA-Turnerambv
authored and
pablogsal
committed
[3.11] gh-93738: Documentation C syntax (Function glob patterns -> literal markup) (GH-97774) (#97910)
(cherry picked from commit 0e72606) Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com> Co-authored-by: Łukasz Langa <lukasz@langa.pl>
1 parent c5d6009 commit 6ff98f7

File tree

7 files changed

+21
-21
lines changed

7 files changed

+21
-21
lines changed

‎Doc/c-api/arg.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -335,7 +335,7 @@ Other objects
335335
status = converter(object, address);
336336

337337
where *object* is the Python object to be converted and *address* is the
338-
:c:expr:`void*` argument that was passed to the ``PyArg_Parse*`` function.
338+
:c:type:`void*` argument that was passed to the ``PyArg_Parse*`` function.
339339
The returned *status* should be ``1`` for a successful conversion and ``0`` if
340340
the conversion has failed. When the conversion fails, the *converter* function
341341
should raise an exception and leave the content of *address* unmodified.
@@ -409,9 +409,9 @@ what is specified for the corresponding format unit in that case.
409409

410410
For the conversion to succeed, the *arg* object must match the format
411411
and the format must be exhausted. On success, the
412-
:c:func:`PyArg_Parse\*` functions return true, otherwise they return
412+
``PyArg_Parse*`` functions return true, otherwise they return
413413
false and raise an appropriate exception. When the
414-
:c:func:`PyArg_Parse\*` functions fail due to conversion failure in one
414+
``PyArg_Parse*`` functions fail due to conversion failure in one
415415
of the format units, the variables at the addresses corresponding to that
416416
and the following format units are left untouched.
417417

@@ -518,7 +518,7 @@ Building values
518518
.. c:function:: PyObject* Py_BuildValue(const char *format, ...)
519519
520520
Create a new value based on a format string similar to those accepted by the
521-
:c:func:`PyArg_Parse\*` family of functions and a sequence of values. Returns
521+
``PyArg_Parse*`` family of functions and a sequence of values. Returns
522522
the value or ``NULL`` in the case of an error; an exception will be raised if
523523
``NULL`` is returned.
524524

‎Doc/c-api/exceptions.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ there is a global indicator (per thread) of the last error that occurred. Most
1414
C API functions don't clear this on success, but will set it to indicate the
1515
cause of the error on failure. Most C API functions also return an error
1616
indicator, usually ``NULL`` if they are supposed to return a pointer, or ``-1``
17-
if they return an integer (exception: the :c:func:`PyArg_\*` functions
17+
if they return an integer (exception: the ``PyArg_*`` functions
1818
return ``1`` for success and ``0`` for failure).
1919

2020
Concretely, the error indicator consists of three object pointers: the
@@ -370,7 +370,7 @@ Querying the error indicator
370370
.. c:function:: PyObject* PyErr_Occurred()
371371
372372
Test whether the error indicator is set. If set, return the exception *type*
373-
(the first argument to the last call to one of the :c:func:`PyErr_Set\*`
373+
(the first argument to the last call to one of the ``PyErr_Set*``
374374
functions or to :c:func:`PyErr_Restore`). If not set, return ``NULL``. You do not
375375
own a reference to the return value, so you do not need to :c:func:`Py_DECREF`
376376
it.

‎Doc/c-api/init.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -847,11 +847,11 @@ from a C thread is::
847847
/* Release the thread. No Python API allowed beyond this point. */
848848
PyGILState_Release(gstate);
849849
850-
Note that the :c:func:`PyGILState_\*` functions assume there is only one global
850+
Note that the ``PyGILState_*`` functions assume there is only one global
851851
interpreter (created automatically by :c:func:`Py_Initialize`). Python
852852
supports the creation of additional interpreters (using
853853
:c:func:`Py_NewInterpreter`), but mixing multiple interpreters and the
854-
:c:func:`PyGILState_\*` API is unsupported.
854+
``PyGILState_*`` API is unsupported.
855855
856856
857857
.. _fork-and-threads:
@@ -1478,7 +1478,7 @@ operations executed by such objects may affect the wrong (sub-)interpreter's
14781478
dictionary of loaded modules. It is equally important to avoid sharing
14791479
objects from which the above are reachable.
14801480
1481-
Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
1481+
Also note that combining this functionality with ``PyGILState_*`` APIs
14821482
is delicate, because these APIs assume a bijection between Python thread states
14831483
and OS-level threads, an assumption broken by the presence of sub-interpreters.
14841484
It is highly recommended that you don't switch sub-interpreters between a pair

‎Doc/c-api/module.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -64,8 +64,8 @@ Module Objects
6464
If *module* is not a module object (or a subtype of a module object),
6565
:exc:`SystemError` is raised and ``NULL`` is returned.
6666
67-
It is recommended extensions use other :c:func:`PyModule_\*` and
68-
:c:func:`PyObject_\*` functions rather than directly manipulate a module's
67+
It is recommended extensions use other ``PyModule_*`` and
68+
``PyObject_*`` functions rather than directly manipulate a module's
6969
:attr:`~object.__dict__`.
7070
7171

‎Doc/c-api/typeobj.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,8 @@ Type Objects
77

88
Perhaps one of the most important structures of the Python object system is the
99
structure that defines a new type: the :c:type:`PyTypeObject` structure. Type
10-
objects can be handled using any of the :c:func:`PyObject_\*` or
11-
:c:func:`PyType_\*` functions, but do not offer much that's interesting to most
10+
objects can be handled using any of the ``PyObject_*`` or
11+
``PyType_*`` functions, but do not offer much that's interesting to most
1212
Python applications. These objects are fundamental to how objects behave, so
1313
they are very important to the interpreter itself and to any extension module
1414
that implements new types.
@@ -1484,8 +1484,8 @@ and :c:type:`PyType_Type` effectively act as defaults.)
14841484
If the instances of this type are weakly referenceable, this field is greater
14851485
than zero and contains the offset in the instance structure of the weak
14861486
reference list head (ignoring the GC header, if present); this offset is used by
1487-
:c:func:`PyObject_ClearWeakRefs` and the :c:func:`PyWeakref_\*` functions. The
1488-
instance structure needs to include a field of type :c:type:`PyObject*` which is
1487+
:c:func:`PyObject_ClearWeakRefs` and the ``PyWeakref_*`` functions. The
1488+
instance structure needs to include a field of type :c:expr:`PyObject*` which is
14891489
initialized to ``NULL``.
14901490

14911491
Do not confuse this field with :c:member:`~PyTypeObject.tp_weaklist`; that is the list head for

‎Doc/extending/extending.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -157,16 +157,16 @@ since you should be able to tell from the return value.
157157

158158
When a function *f* that calls another function *g* detects that the latter
159159
fails, *f* should itself return an error value (usually ``NULL`` or ``-1``). It
160-
should *not* call one of the :c:func:`PyErr_\*` functions --- one has already
160+
should *not* call one of the ``PyErr_*`` functions --- one has already
161161
been called by *g*. *f*'s caller is then supposed to also return an error
162-
indication to *its* caller, again *without* calling :c:func:`PyErr_\*`, and so on
162+
indication to *its* caller, again *without* calling ``PyErr_*``, and so on
163163
--- the most detailed cause of the error was already reported by the function
164164
that first detected it. Once the error reaches the Python interpreter's main
165165
loop, this aborts the currently executing Python code and tries to find an
166166
exception handler specified by the Python programmer.
167167

168168
(There are situations where a module can actually give a more detailed error
169-
message by calling another :c:func:`PyErr_\*` function, and in such cases it is
169+
message by calling another ``PyErr_*`` function, and in such cases it is
170170
fine to do so. As a general rule, however, this is not necessary, and can cause
171171
information about the cause of the error to be lost: most operations can fail
172172
for a variety of reasons.)

‎Doc/whatsnew/2.5.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2270,9 +2270,9 @@ code:
22702270
earlier section :ref:`pep-353` for a discussion of this change.
22712271

22722272
* C API: The obmalloc changes mean that you must be careful to not mix usage
2273-
of the :c:func:`PyMem_\*` and :c:func:`PyObject_\*` families of functions. Memory
2274-
allocated with one family's :c:func:`\*_Malloc` must be freed with the
2275-
corresponding family's :c:func:`\*_Free` function.
2273+
of the ``PyMem_*`` and ``PyObject_*`` families of functions. Memory
2274+
allocated with one family's ``*_Malloc`` must be freed with the
2275+
corresponding family's ``*_Free`` function.
22762276

22772277
.. ======================================================================
22782278

0 commit comments

Comments
 (0)
0