mirror of https://github.com/python/cpython
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
|
@ -253,6 +253,14 @@ For convenience, some of these functions will always return a
|
|||
.. versionadded:: 3.3
|
||||
|
||||
|
||||
.. c:function:: PyObject* PyErr_SetImportErrorSubclass(PyObject *exception, PyObject *msg, PyObject *name, PyObject *path)
|
||||
|
||||
Much like :c:func:`PyErr_SetImportError` but this function allows for
|
||||
specifying a subclass of :exc:`ImportError` to raise.
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
|
||||
.. c:function:: void PyErr_SyntaxLocationObject(PyObject *filename, int lineno, int col_offset)
|
||||
|
||||
Set file, line, and offset information for the current exception. If the
|
||||
|
@ -320,13 +328,6 @@ an error value).
|
|||
:mod:`warnings` module and the :option:`-W` option in the command line
|
||||
documentation. There is no C API for warning control.
|
||||
|
||||
.. c:function:: PyObject* PyErr_SetImportErrorSubclass(PyObject *exception, PyObject *msg, PyObject *name, PyObject *path)
|
||||
|
||||
Much like :c:func:`PyErr_SetImportError` but this function allows for
|
||||
specifying a subclass of :exc:`ImportError` to raise.
|
||||
|
||||
.. versionadded:: 3.6
|
||||
|
||||
|
||||
.. c:function:: int PyErr_WarnExplicitObject(PyObject *category, PyObject *message, PyObject *filename, int lineno, PyObject *module, PyObject *registry)
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -1003,7 +1003,7 @@ Error handling is set by errors which may also be set to ``NULL`` meaning to use
|
|||
the default handling defined for the codec. Default error handling for all
|
||||
built-in codecs is "strict" (:exc:`ValueError` is raised).
|
||||
|
||||
The codecs all use a similar interface. Only deviation from the following
|
||||
The codecs all use a similar interface. Only deviations from the following
|
||||
generic ones are documented for simplicity.
|
||||
|
||||
|
||||
|
@ -1171,7 +1171,7 @@ These are the UTF-16 codec APIs:
|
|||
``1``, any byte order mark is copied to the output (where it will result in
|
||||
either a ``\ufeff`` or a ``\ufffe`` character).
|
||||
|
||||
After completion, *\*byteorder* is set to the current byte order at the end
|
||||
After completion, ``*byteorder`` is set to the current byte order at the end
|
||||
of input data.
|
||||
|
||||
If *byteorder* is ``NULL``, the codec starts in native order mode.
|
||||
|
@ -1302,7 +1302,7 @@ Character Map Codecs
|
|||
|
||||
This codec is special in that it can be used to implement many different codecs
|
||||
(and this is in fact what was done to obtain most of the standard codecs
|
||||
included in the :mod:`encodings` package). The codec uses mapping to encode and
|
||||
included in the :mod:`encodings` package). The codec uses mappings to encode and
|
||||
decode characters. The mapping objects provided must support the
|
||||
:meth:`__getitem__` mapping interface; dictionaries and sequences work well.
|
||||
|
||||
|
@ -1426,7 +1426,7 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
|
|||
.. c:function:: PyObject* PyUnicode_Splitlines(PyObject *s, int keepend)
|
||||
|
||||
Split a Unicode string at line breaks, returning a list of Unicode strings.
|
||||
CRLF is considered to be one line break. If *keepend* is ``0``, the Line break
|
||||
CRLF is considered to be one line break. If *keepend* is ``0``, the line break
|
||||
characters are not included in the resulting strings.
|
||||
|
||||
|
||||
|
|
|
@ -75,6 +75,8 @@ the same library that the Python runtime is using.
|
|||
:c:func:`PyRun_SimpleFile`. *filename* is decoded from the filesystem
|
||||
encoding (:func:`sys.getfilesystemencoding`). If *filename* is ``NULL``, this
|
||||
function uses ``"???"`` as the filename.
|
||||
If *closeit* is true, the file is closed before
|
||||
``PyRun_SimpleFileExFlags()`` returns.
|
||||
|
||||
|
||||
.. c:function:: int PyRun_SimpleString(const char *command)
|
||||
|
|
Loading…
Reference in New Issue