mirror of
https://github.com/python/cpython
synced 2026-09-29 12:10:30 +03:00
Minor fixes to C API docs (GH-31501)
* C API docs: move PyErr_SetImportErrorSubclass docs It was in the section about warnings, but it makes more sense to put it with PyErr_SetImportError. * C API docs: document closeit argument to PyRun_AnyFileExFlags It was already documented for PyRun_SimpleFileExFlags. * textual fixes to unicode docs * Move paragraph about tp_dealloc into tp_dealloc section * __aiter__ returns an async iterator, not an awaitable
This commit is contained in:
parent
1935e1cc28
commit
43cf44ddcc
4 changed files with 28 additions and 24 deletions
|
|
@ -476,7 +476,7 @@ PyObject Slots
|
|||
--------------
|
||||
|
||||
The type object structure extends the :c:type:`PyVarObject` structure. The
|
||||
:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
|
||||
:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
|
||||
usually called from a class statement). Note that :c:data:`PyType_Type` (the
|
||||
metatype) initializes :c:member:`~PyTypeObject.tp_itemsize`, which means that its instances (i.e.
|
||||
type objects) *must* have the :attr:`ob_size` field.
|
||||
|
|
@ -2000,6 +2000,17 @@ and :c:type:`PyType_Type` effectively act as defaults.)
|
|||
For this field to be taken into account (even through inheritance),
|
||||
you must also set the :const:`Py_TPFLAGS_HAVE_FINALIZE` flags bit.
|
||||
|
||||
Also, note that, in a garbage collected Python,
|
||||
:c:member:`~PyTypeObject.tp_dealloc` may be called from
|
||||
any Python thread, not just the thread which created the object (if the object
|
||||
becomes part of a refcount cycle, that cycle might be collected by a garbage
|
||||
collection on any thread). This is not a problem for Python API calls, since
|
||||
the thread on which tp_dealloc is called will own the Global Interpreter Lock
|
||||
(GIL). However, if the object being destroyed in turn destroys objects from some
|
||||
other C or C++ library, care should be taken to ensure that destroying those
|
||||
objects on the thread which called tp_dealloc will not violate any assumptions
|
||||
of the library.
|
||||
|
||||
**Inheritance:**
|
||||
|
||||
This field is inherited by subtypes.
|
||||
|
|
@ -2024,17 +2035,6 @@ and :c:type:`PyType_Type` effectively act as defaults.)
|
|||
.. versionadded:: 3.9 (the field exists since 3.8 but it's only used since 3.9)
|
||||
|
||||
|
||||
Also, note that, in a garbage collected Python, :c:member:`~PyTypeObject.tp_dealloc` may be called from
|
||||
any Python thread, not just the thread which created the object (if the object
|
||||
becomes part of a refcount cycle, that cycle might be collected by a garbage
|
||||
collection on any thread). This is not a problem for Python API calls, since
|
||||
the thread on which tp_dealloc is called will own the Global Interpreter Lock
|
||||
(GIL). However, if the object being destroyed in turn destroys objects from some
|
||||
other C or C++ library, care should be taken to ensure that destroying those
|
||||
objects on the thread which called tp_dealloc will not violate any assumptions
|
||||
of the library.
|
||||
|
||||
|
||||
.. _static-types:
|
||||
|
||||
Static Types
|
||||
|
|
@ -2440,7 +2440,8 @@ Async Object Structures
|
|||
|
||||
PyObject *am_aiter(PyObject *self);
|
||||
|
||||
Must return an :term:`awaitable` object. See :meth:`__anext__` for details.
|
||||
Must return an :term:`asynchronous iterator` object.
|
||||
See :meth:`__anext__` for details.
|
||||
|
||||
This slot may be set to ``NULL`` if an object does not implement
|
||||
asynchronous iteration protocol.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue