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
.. 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
.. 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)``.
.. 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
``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
.. 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
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.
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
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);
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.
(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`.)
* :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`.)
.. 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`.
..
.. 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.
..
projects / thirdparty / Python / cpython.git / commitdiff
