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:
Jelle Zijlstra 2022-02-22 20:34:17 -08:00 • committed by GitHub
parent 1935e1cc28
commit 43cf44ddcc
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 28 additions and 24 deletions

View file

@ -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.