mirror of
https://github.com/python/cpython.git
synced 2025-07-24 19:54:21 +00:00
gh-107091: Fix some uses of :c:member: role (GH-107129)
This commit is contained in:
parent
737d1da074
commit
af61cb9c78
8 changed files with 16 additions and 14 deletions
|
@ -154,7 +154,7 @@ Importing Modules
|
|||
:class:`SourceFileLoader` otherwise.
|
||||
|
||||
The module's :attr:`__file__` attribute will be set to the code object's
|
||||
:c:member:`co_filename`. If applicable, :attr:`__cached__` will also
|
||||
:attr:`co_filename`. If applicable, :attr:`__cached__` will also
|
||||
be set.
|
||||
|
||||
This function will reload the module if it was already imported. See
|
||||
|
|
|
@ -522,7 +522,7 @@ PyConfig
|
|||
Moreover, if :c:func:`PyConfig_SetArgv` or :c:func:`PyConfig_SetBytesArgv`
|
||||
is used, this method must be called before other methods, since the
|
||||
preinitialization configuration depends on command line arguments (if
|
||||
:c:member:`parse_argv` is non-zero).
|
||||
:c:member:`~PyConfig.parse_argv` is non-zero).
|
||||
|
||||
The caller of these methods is responsible to handle exceptions (error or
|
||||
exit) using ``PyStatus_Exception()`` and ``Py_ExitStatusException()``.
|
||||
|
|
|
@ -164,7 +164,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
|
|||
|
||||
This memory area is allocated based on *m_size* on module creation,
|
||||
and freed when the module object is deallocated, after the
|
||||
:c:member:`m_free` function has been called, if present.
|
||||
:c:member:`~PyModuleDef.m_free` function has been called, if present.
|
||||
|
||||
Setting ``m_size`` to ``-1`` means that the module does not support
|
||||
sub-interpreters, because it has global state.
|
||||
|
@ -202,7 +202,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
|
|||
This function is not called if the module state was requested but is not
|
||||
allocated yet. This is the case immediately after the module is created
|
||||
and before the module is executed (:c:data:`Py_mod_exec` function). More
|
||||
precisely, this function is not called if :c:member:`m_size` is greater
|
||||
precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
|
||||
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
|
||||
is ``NULL``.
|
||||
|
||||
|
@ -217,7 +217,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
|
|||
This function is not called if the module state was requested but is not
|
||||
allocated yet. This is the case immediately after the module is created
|
||||
and before the module is executed (:c:data:`Py_mod_exec` function). More
|
||||
precisely, this function is not called if :c:member:`m_size` is greater
|
||||
precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
|
||||
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
|
||||
is ``NULL``.
|
||||
|
||||
|
@ -238,7 +238,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
|
|||
This function is not called if the module state was requested but is not
|
||||
allocated yet. This is the case immediately after the module is created
|
||||
and before the module is executed (:c:data:`Py_mod_exec` function). More
|
||||
precisely, this function is not called if :c:member:`m_size` is greater
|
||||
precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
|
||||
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
|
||||
is ``NULL``.
|
||||
|
||||
|
|
|
@ -244,14 +244,16 @@ Implementing functions and methods
|
|||
|
||||
points to the contents of the docstring
|
||||
|
||||
The :c:member:`ml_meth` is a C function pointer. The functions may be of different
|
||||
The :c:member:`~PyMethodDef.ml_meth` is a C function pointer.
|
||||
The functions may be of different
|
||||
types, but they always return :c:expr:`PyObject*`. If the function is not of
|
||||
the :c:type:`PyCFunction`, the compiler will require a cast in the method table.
|
||||
Even though :c:type:`PyCFunction` defines the first parameter as
|
||||
:c:expr:`PyObject*`, it is common that the method implementation uses the
|
||||
specific C type of the *self* object.
|
||||
|
||||
The :c:member:`ml_flags` field is a bitfield which can include the following flags.
|
||||
The :c:member:`~PyMethodDef.ml_flags` field is a bitfield which can include
|
||||
the following flags.
|
||||
The individual flags indicate either a calling convention or a binding
|
||||
convention.
|
||||
|
||||
|
@ -432,7 +434,7 @@ Accessing attributes of extension types
|
|||
The string should be static, no copy is made of it.
|
||||
Typically, it is defined using :c:macro:`PyDoc_STR`.
|
||||
|
||||
By default (when :c:member:`flags` is ``0``), members allow
|
||||
By default (when :c:member:`~PyMemberDef.flags` is ``0``), members allow
|
||||
both read and write access.
|
||||
Use the :c:macro:`Py_READONLY` flag for read-only access.
|
||||
Certain types, like :c:macro:`Py_T_STRING`, imply :c:macro:`Py_READONLY`.
|
||||
|
@ -512,7 +514,7 @@ The following flags can be used with :c:member:`PyMemberDef.flags`:
|
|||
|
||||
Can only be used as part of :c:member:`Py_tp_members <PyTypeObject.tp_members>`
|
||||
:c:type:`slot <PyTypeSlot>` when creating a class using negative
|
||||
:c:member:`~PyTypeDef.basicsize`.
|
||||
:c:member:`~PyType_Spec.basicsize`.
|
||||
It is mandatory in that case.
|
||||
|
||||
This flag is only used in :c:type:`PyTypeSlot`.
|
||||
|
|
|
@ -1176,7 +1176,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
|
|||
.. c:macro:: Py_TPFLAGS_ITEMS_AT_END
|
||||
|
||||
Only usable with variable-size types, i.e. ones with non-zero
|
||||
:c:member:`~PyObject.tp_itemsize`.
|
||||
:c:member:`~PyTypeObject.tp_itemsize`.
|
||||
|
||||
Indicates that the variable-sized portion of an instance of this type is
|
||||
at the end of the instance's memory area, at an offset of
|
||||
|
|
|
@ -467,7 +467,7 @@ Module State Access from Slot Methods, Getters and Setters
|
|||
|
||||
Slot methods—the fast C equivalents for special methods, such as
|
||||
:c:member:`~PyNumberMethods.nb_add` for :py:attr:`~object.__add__` or
|
||||
:c:member:`~PyType.tp_new` for initialization—have a very simple API that
|
||||
:c:member:`~PyTypeObject.tp_new` for initialization—have a very simple API that
|
||||
doesn't allow passing in the defining class, unlike with :c:type:`PyCMethod`.
|
||||
The same goes for getters and setters defined with
|
||||
:c:type:`PyGetSetDef`.
|
||||
|
|
|
@ -2533,7 +2533,7 @@ Changes in the C API
|
|||
|
||||
* As part of the :pep:`492` implementation, the ``tp_reserved`` slot of
|
||||
:c:type:`PyTypeObject` was replaced with a
|
||||
:c:member:`tp_as_async` slot. Refer to :ref:`coro-objects` for
|
||||
:c:member:`~PyTypeObject.tp_as_async` slot. Refer to :ref:`coro-objects` for
|
||||
new types, structures and functions.
|
||||
|
||||
|
||||
|
|
|
@ -1674,7 +1674,7 @@ The new :c:func:`import__find__load__start` and
|
|||
module imports.
|
||||
(Contributed by Christian Heimes in :issue:`31574`.)
|
||||
|
||||
The fields :c:member:`name` and :c:member:`doc` of structures
|
||||
The fields :c:member:`!name` and :c:member:`!doc` of structures
|
||||
:c:type:`PyMemberDef`, :c:type:`PyGetSetDef`,
|
||||
:c:type:`PyStructSequence_Field`, :c:type:`PyStructSequence_Desc`,
|
||||
and :c:type:`wrapperbase` are now of type ``const char *`` rather of
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue