mirror of https://github.com/python/cpython
gh-107091: Fix the use of some C domain roles (#107092)
This commit is contained in:
parent
c65592c4d6
commit
08a228da05
|
@ -225,7 +225,7 @@ object via :c:func:`PyObject_GetBuffer`. Since the complexity of the logical
|
|||
structure of the memory can vary drastically, the consumer uses the *flags*
|
||||
argument to specify the exact buffer type it can handle.
|
||||
|
||||
All :c:data:`Py_buffer` fields are unambiguously defined by the request
|
||||
All :c:type:`Py_buffer` fields are unambiguously defined by the request
|
||||
type.
|
||||
|
||||
request-independent fields
|
||||
|
@ -464,7 +464,7 @@ Buffer-related functions
|
|||
|
||||
.. c:function:: Py_ssize_t PyBuffer_SizeFromFormat(const char *format)
|
||||
|
||||
Return the implied :c:data:`~Py_buffer.itemsize` from :c:data:`~Py_buffer.format`.
|
||||
Return the implied :c:member:`~Py_buffer.itemsize` from :c:member:`~Py_buffer.format`.
|
||||
On error, raise an exception and return -1.
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
|
|
@ -7,8 +7,8 @@ Instance Method Objects
|
|||
|
||||
.. index:: pair: object; instancemethod
|
||||
|
||||
An instance method is a wrapper for a :c:data:`PyCFunction` and the new way
|
||||
to bind a :c:data:`PyCFunction` to a class object. It replaces the former call
|
||||
An instance method is a wrapper for a :c:type:`PyCFunction` and the new way
|
||||
to bind a :c:type:`PyCFunction` to a class object. It replaces the former call
|
||||
``PyMethod_New(func, NULL, class)``.
|
||||
|
||||
|
||||
|
|
|
@ -145,7 +145,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
|
|||
|
||||
.. c:member:: PyModuleDef_Base m_base
|
||||
|
||||
Always initialize this member to :c:data:`PyModuleDef_HEAD_INIT`.
|
||||
Always initialize this member to :c:macro:`PyModuleDef_HEAD_INIT`.
|
||||
|
||||
.. c:member:: const char *m_name
|
||||
|
||||
|
|
|
@ -215,7 +215,7 @@ Type Objects
|
|||
``Py_TYPE(self)`` may be a *subclass* of the intended class, and subclasses
|
||||
are not necessarily defined in the same module as their superclass.
|
||||
See :c:type:`PyCMethod` to get the class that defines the method.
|
||||
See :c:func:`PyType_GetModuleByDef` for cases when ``PyCMethod`` cannot
|
||||
See :c:func:`PyType_GetModuleByDef` for cases when :c:type:`!PyCMethod` cannot
|
||||
be used.
|
||||
|
||||
.. versionadded:: 3.9
|
||||
|
|
|
@ -2255,8 +2255,8 @@ Number Object Structures
|
|||
|
||||
.. note::
|
||||
|
||||
The :c:data:`nb_reserved` field should always be ``NULL``. It
|
||||
was previously called :c:data:`nb_long`, and was renamed in
|
||||
The :c:member:`~PyNumberMethods.nb_reserved` field should always be ``NULL``. It
|
||||
was previously called :c:member:`!nb_long`, and was renamed in
|
||||
Python 3.0.1.
|
||||
|
||||
.. c:member:: binaryfunc PyNumberMethods.nb_add
|
||||
|
|
|
@ -237,10 +237,10 @@ Note that the Python name for the exception object is :exc:`spam.error`. The
|
|||
being :exc:`Exception` (unless another class is passed in instead of ``NULL``),
|
||||
described in :ref:`bltin-exceptions`.
|
||||
|
||||
Note also that the :c:data:`SpamError` variable retains a reference to the newly
|
||||
Note also that the :c:data:`!SpamError` variable retains a reference to the newly
|
||||
created exception class; this is intentional! Since the exception could be
|
||||
removed from the module by external code, an owned reference to the class is
|
||||
needed to ensure that it will not be discarded, causing :c:data:`SpamError` to
|
||||
needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
|
||||
become a dangling pointer. Should it become a dangling pointer, C code which
|
||||
raises the exception could cause a core dump or other unintended side effects.
|
||||
|
||||
|
@ -281,9 +281,9 @@ statement::
|
|||
It returns ``NULL`` (the error indicator for functions returning object pointers)
|
||||
if an error is detected in the argument list, relying on the exception set by
|
||||
:c:func:`PyArg_ParseTuple`. Otherwise the string value of the argument has been
|
||||
copied to the local variable :c:data:`command`. This is a pointer assignment and
|
||||
copied to the local variable :c:data:`!command`. This is a pointer assignment and
|
||||
you are not supposed to modify the string to which it points (so in Standard C,
|
||||
the variable :c:data:`command` should properly be declared as ``const char
|
||||
the variable :c:data:`!command` should properly be declared as ``const char
|
||||
*command``).
|
||||
|
||||
The next statement is a call to the Unix function :c:func:`system`, passing it
|
||||
|
@ -291,7 +291,7 @@ the string we just got from :c:func:`PyArg_ParseTuple`::
|
|||
|
||||
sts = system(command);
|
||||
|
||||
Our :func:`spam.system` function must return the value of :c:data:`sts` as a
|
||||
Our :func:`!spam.system` function must return the value of :c:data:`!sts` as a
|
||||
Python object. This is done using the function :c:func:`PyLong_FromLong`. ::
|
||||
|
||||
return PyLong_FromLong(sts);
|
||||
|
|
|
@ -483,14 +483,14 @@ to get the state::
|
|||
return NULL;
|
||||
}
|
||||
|
||||
``PyType_GetModuleByDef`` works by searching the
|
||||
:c:func:`!PyType_GetModuleByDef` works by searching the
|
||||
:term:`method resolution order` (i.e. all superclasses) for the first
|
||||
superclass that has a corresponding module.
|
||||
|
||||
.. note::
|
||||
|
||||
In very exotic cases (inheritance chains spanning multiple modules
|
||||
created from the same definition), ``PyType_GetModuleByDef`` might not
|
||||
created from the same definition), :c:func:`!PyType_GetModuleByDef` might not
|
||||
return the module of the true defining class. However, it will always
|
||||
return a module with the same definition, ensuring a compatible
|
||||
C memory layout.
|
||||
|
|
|
@ -2227,7 +2227,7 @@ New Features
|
|||
|
||||
(Contributed by Christian Heimes in :issue:`45459`.)
|
||||
|
||||
* Added the :c:data:`PyType_GetModuleByDef` function, used to get the module
|
||||
* Added the :c:func:`PyType_GetModuleByDef` function, used to get the module
|
||||
in which a method was defined, in cases where this information is not
|
||||
available directly (via :c:type:`PyCMethod`).
|
||||
(Contributed by Petr Viktorin in :issue:`46613`.)
|
||||
|
|
|
@ -1276,7 +1276,7 @@ New Features
|
|||
* :pep:`573`: Added :c:func:`PyType_FromModuleAndSpec` to associate
|
||||
a module with a class; :c:func:`PyType_GetModule` and
|
||||
:c:func:`PyType_GetModuleState` to retrieve the module and its state; and
|
||||
:c:data:`PyCMethod` and :c:macro:`METH_METHOD` to allow a method to
|
||||
:c:type:`PyCMethod` and :c:macro:`METH_METHOD` to allow a method to
|
||||
access the class it was defined in.
|
||||
(Contributed by Marcel Plch and Petr Viktorin in :issue:`38787`.)
|
||||
|
||||
|
|
|
@ -847,8 +847,8 @@ Victor Stinner.
|
|||
.. section: C API
|
||||
|
||||
Fix potential crash in deallocating method objects when dynamically
|
||||
allocated `PyMethodDef`'s lifetime is managed through the ``self`` argument
|
||||
of a `PyCFunction`.
|
||||
allocated :c:type:`PyMethodDef`'s lifetime is managed through the ``self`` argument
|
||||
of a :c:type:`PyCFunction`.
|
||||
|
||||
..
|
||||
|
||||
|
|
|
@ -5934,7 +5934,7 @@ not override :c:member:`~PyTypeObject.tp_call` now inherit the
|
|||
.. nonce: aiRSgr
|
||||
.. section: C API
|
||||
|
||||
Creating :c:data:`immutable types <Py_TPFLAGS_IMMUTABLETYPE>` with mutable
|
||||
Creating :c:macro:`immutable types <Py_TPFLAGS_IMMUTABLETYPE>` with mutable
|
||||
bases is deprecated and is planned to be disabled in Python 3.14.
|
||||
|
||||
..
|
||||
|
|
Loading…
Reference in New Issue