Skip to content

Commit a8df902

Browse files
JelleZijlstrahello-adam
authored andcommitted
[3.9] Minor fixes to C API docs (pythonGH-31501) (pythonGH-31526)
* 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. (cherry picked from commit 43cf44d)
1 parent 87b4259 commit a8df902

File tree

4 files changed

+28
-24
lines changed

4 files changed

+28
-24
lines changed

Doc/c-api/exceptions.rst

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -253,6 +253,14 @@ For convenience, some of these functions will always return a
253253
.. versionadded:: 3.3
254254
255255
256+
.. c:function:: PyObject* PyErr_SetImportErrorSubclass(PyObject *exception, PyObject *msg, PyObject *name, PyObject *path)
257+
258+
Much like :c:func:`PyErr_SetImportError` but this function allows for
259+
specifying a subclass of :exc:`ImportError` to raise.
260+
261+
.. versionadded:: 3.6
262+
263+
256264
.. c:function:: void PyErr_SyntaxLocationObject(PyObject *filename, int lineno, int col_offset)
257265
258266
Set file, line, and offset information for the current exception. If the
@@ -320,13 +328,6 @@ an error value).
320328
:mod:`warnings` module and the :option:`-W` option in the command line
321329
documentation. There is no C API for warning control.
322330
323-
.. c:function:: PyObject* PyErr_SetImportErrorSubclass(PyObject *exception, PyObject *msg, PyObject *name, PyObject *path)
324-
325-
Much like :c:func:`PyErr_SetImportError` but this function allows for
326-
specifying a subclass of :exc:`ImportError` to raise.
327-
328-
.. versionadded:: 3.6
329-
330331
331332
.. c:function:: int PyErr_WarnExplicitObject(PyObject *category, PyObject *message, PyObject *filename, int lineno, PyObject *module, PyObject *registry)
332333

Doc/c-api/typeobj.rst

Lines changed: 14 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -474,7 +474,7 @@ PyObject Slots
474474
--------------
475475

476476
The type object structure extends the :c:type:`PyVarObject` structure. The
477-
:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
477+
:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
478478
usually called from a class statement). Note that :c:data:`PyType_Type` (the
479479
metatype) initializes :c:member:`~PyTypeObject.tp_itemsize`, which means that its instances (i.e.
480480
type objects) *must* have the :attr:`ob_size` field.
@@ -1909,6 +1909,17 @@ and :c:type:`PyType_Type` effectively act as defaults.)
19091909
For this field to be taken into account (even through inheritance),
19101910
you must also set the :const:`Py_TPFLAGS_HAVE_FINALIZE` flags bit.
19111911

1912+
Also, note that, in a garbage collected Python,
1913+
:c:member:`~PyTypeObject.tp_dealloc` may be called from
1914+
any Python thread, not just the thread which created the object (if the object
1915+
becomes part of a refcount cycle, that cycle might be collected by a garbage
1916+
collection on any thread). This is not a problem for Python API calls, since
1917+
the thread on which tp_dealloc is called will own the Global Interpreter Lock
1918+
(GIL). However, if the object being destroyed in turn destroys objects from some
1919+
other C or C++ library, care should be taken to ensure that destroying those
1920+
objects on the thread which called tp_dealloc will not violate any assumptions
1921+
of the library.
1922+
19121923
**Inheritance:**
19131924

19141925
This field is inherited by subtypes.
@@ -1933,17 +1944,6 @@ and :c:type:`PyType_Type` effectively act as defaults.)
19331944
.. versionadded:: 3.9 (the field exists since 3.8 but it's only used since 3.9)
19341945

19351946

1936-
Also, note that, in a garbage collected Python, :c:member:`~PyTypeObject.tp_dealloc` may be called from
1937-
any Python thread, not just the thread which created the object (if the object
1938-
becomes part of a refcount cycle, that cycle might be collected by a garbage
1939-
collection on any thread). This is not a problem for Python API calls, since
1940-
the thread on which tp_dealloc is called will own the Global Interpreter Lock
1941-
(GIL). However, if the object being destroyed in turn destroys objects from some
1942-
other C or C++ library, care should be taken to ensure that destroying those
1943-
objects on the thread which called tp_dealloc will not violate any assumptions
1944-
of the library.
1945-
1946-
19471947
.. _heap-types:
19481948

19491949
Heap Types
@@ -2340,7 +2340,8 @@ Async Object Structures
23402340

23412341
PyObject *am_aiter(PyObject *self);
23422342

2343-
Must return an :term:`awaitable` object. See :meth:`__anext__` for details.
2343+
Must return an :term:`asynchronous iterator` object.
2344+
See :meth:`__anext__` for details.
23442345

23452346
This slot may be set to ``NULL`` if an object does not implement
23462347
asynchronous iteration protocol.

Doc/c-api/unicode.rst

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1025,7 +1025,7 @@ Error handling is set by errors which may also be set to ``NULL`` meaning to use
10251025
the default handling defined for the codec. Default error handling for all
10261026
built-in codecs is "strict" (:exc:`ValueError` is raised).
10271027
1028-
The codecs all use a similar interface. Only deviation from the following
1028+
The codecs all use a similar interface. Only deviations from the following
10291029
generic ones are documented for simplicity.
10301030
10311031
@@ -1239,7 +1239,7 @@ These are the UTF-16 codec APIs:
12391239
``1``, any byte order mark is copied to the output (where it will result in
12401240
either a ``\ufeff`` or a ``\ufffe`` character).
12411241
1242-
After completion, *\*byteorder* is set to the current byte order at the end
1242+
After completion, ``*byteorder`` is set to the current byte order at the end
12431243
of input data.
12441244
12451245
If *byteorder* is ``NULL``, the codec starts in native order mode.
@@ -1457,7 +1457,7 @@ Character Map Codecs
14571457
14581458
This codec is special in that it can be used to implement many different codecs
14591459
(and this is in fact what was done to obtain most of the standard codecs
1460-
included in the :mod:`encodings` package). The codec uses mapping to encode and
1460+
included in the :mod:`encodings` package). The codec uses mappings to encode and
14611461
decode characters. The mapping objects provided must support the
14621462
:meth:`__getitem__` mapping interface; dictionaries and sequences work well.
14631463
@@ -1619,7 +1619,7 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
16191619
.. c:function:: PyObject* PyUnicode_Splitlines(PyObject *s, int keepend)
16201620
16211621
Split a Unicode string at line breaks, returning a list of Unicode strings.
1622-
CRLF is considered to be one line break. If *keepend* is ``0``, the Line break
1622+
CRLF is considered to be one line break. If *keepend* is ``0``, the line break
16231623
characters are not included in the resulting strings.
16241624
16251625

Doc/c-api/veryhigh.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -75,6 +75,8 @@ the same library that the Python runtime is using.
7575
:c:func:`PyRun_SimpleFile`. *filename* is decoded from the filesystem
7676
encoding (:func:`sys.getfilesystemencoding`). If *filename* is ``NULL``, this
7777
function uses ``"???"`` as the filename.
78+
If *closeit* is true, the file is closed before
79+
``PyRun_SimpleFileExFlags()`` returns.
7880
7981
8082
.. c:function:: int PyRun_SimpleString(const char *command)

0 commit comments

Comments
 (0)