mirror of
https://github.com/python/cpython.git
synced 2025-09-26 10:19:53 +00:00
[3.12] gh-107298: Fix more Sphinx warnings in the C API doc (GH-107329) (GH-107376)
Declare the following functions as macros, since they are actually
macros. It avoids a warning on "TYPE" or "macro" argument.
* PyMem_New()
* PyMem_Resize()
* PyModule_AddIntMacro()
* PyModule_AddStringMacro()
* PyObject_GC_New()
* PyObject_GC_NewVar()
* PyObject_New()
* PyObject_NewVar()
Add C standard C types to nitpick_ignore in Doc/conf.py:
* int64_t
* uint64_t
* uintptr_t
No longer ignore non existing "__int" type in nitpick_ignore.
Update Doc/tools/.nitignore.
(cherry picked from commit 8d61a71f9c
)
Co-authored-by: Victor Stinner <vstinner@python.org>
This commit is contained in:
parent
ef7422a1b9
commit
e6a4b10820
23 changed files with 122 additions and 119 deletions
|
@ -27,22 +27,25 @@ Allocating Objects on the Heap
|
|||
length information for a variable-size object.
|
||||
|
||||
|
||||
.. c:function:: TYPE* PyObject_New(TYPE, PyTypeObject *type)
|
||||
.. c:macro:: PyObject_New(TYPE, typeobj)
|
||||
|
||||
Allocate a new Python object using the C structure type *TYPE* and the
|
||||
Python type object *type*. Fields not defined by the Python object header
|
||||
Python type object *typeobj* (``PyTypeObject*``).
|
||||
Fields not defined by the Python object header
|
||||
are not initialized; the object's reference count will be one. The size of
|
||||
the memory allocation is determined from the :c:member:`~PyTypeObject.tp_basicsize` field of
|
||||
the type object.
|
||||
|
||||
|
||||
.. c:function:: TYPE* PyObject_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
|
||||
.. c:macro:: PyObject_NewVar(TYPE, typeobj, size)
|
||||
|
||||
Allocate a new Python object using the C structure type *TYPE* and the
|
||||
Python type object *type*. Fields not defined by the Python object header
|
||||
Python type object *typeobj* (``PyTypeObject*``).
|
||||
Fields not defined by the Python object header
|
||||
are not initialized. The allocated memory allows for the *TYPE* structure
|
||||
plus *size* fields of the size given by the :c:member:`~PyTypeObject.tp_itemsize` field of
|
||||
*type*. This is useful for implementing objects like tuples, which are
|
||||
plus *size* (``Py_ssize_t``) fields of the size
|
||||
given by the :c:member:`~PyTypeObject.tp_itemsize` field of
|
||||
*typeobj*. This is useful for implementing objects like tuples, which are
|
||||
able to determine their size at construction time. Embedding the array of
|
||||
fields into the same allocation decreases the number of allocations,
|
||||
improving the memory management efficiency.
|
||||
|
@ -50,8 +53,8 @@ Allocating Objects on the Heap
|
|||
|
||||
.. c:function:: void PyObject_Del(void *op)
|
||||
|
||||
Releases memory allocated to an object using :c:func:`PyObject_New` or
|
||||
:c:func:`PyObject_NewVar`. This is normally called from the
|
||||
Releases memory allocated to an object using :c:macro:`PyObject_New` or
|
||||
:c:macro:`PyObject_NewVar`. This is normally called from the
|
||||
:c:member:`~PyTypeObject.tp_dealloc` handler specified in the object's type. The fields of
|
||||
the object should not be accessed after this call as the memory is no
|
||||
longer a valid Python object.
|
||||
|
|
|
@ -64,7 +64,7 @@ Refer to :ref:`using-capsules` for more information on using these objects.
|
|||
|
||||
The *name* parameter must compare exactly to the name stored in the capsule.
|
||||
If the name stored in the capsule is ``NULL``, the *name* passed in must also
|
||||
be ``NULL``. Python uses the C function :c:func:`strcmp` to compare capsule
|
||||
be ``NULL``. Python uses the C function :c:func:`!strcmp` to compare capsule
|
||||
names.
|
||||
|
||||
|
||||
|
|
|
@ -64,7 +64,7 @@ pointers. This is consistent throughout the API.
|
|||
representation.
|
||||
|
||||
If *divisor* is null, this method returns zero and sets
|
||||
:c:data:`errno` to :c:macro:`EDOM`.
|
||||
:c:data:`errno` to :c:macro:`!EDOM`.
|
||||
|
||||
|
||||
.. c:function:: Py_complex _Py_c_pow(Py_complex num, Py_complex exp)
|
||||
|
@ -73,7 +73,7 @@ pointers. This is consistent throughout the API.
|
|||
representation.
|
||||
|
||||
If *num* is null and *exp* is not a positive real number,
|
||||
this method returns zero and sets :c:data:`errno` to :c:macro:`EDOM`.
|
||||
this method returns zero and sets :c:data:`errno` to :c:macro:`!EDOM`.
|
||||
|
||||
|
||||
Complex Numbers as Python Objects
|
||||
|
|
|
@ -119,10 +119,10 @@ The following functions provide locale-independent string to number conversions.
|
|||
.. c:function:: int PyOS_stricmp(const char *s1, const char *s2)
|
||||
|
||||
Case insensitive comparison of strings. The function works almost
|
||||
identically to :c:func:`strcmp` except that it ignores the case.
|
||||
identically to :c:func:`!strcmp` except that it ignores the case.
|
||||
|
||||
|
||||
.. c:function:: int PyOS_strnicmp(const char *s1, const char *s2, Py_ssize_t size)
|
||||
|
||||
Case insensitive comparison of strings. The function works almost
|
||||
identically to :c:func:`strncmp` except that it ignores the case.
|
||||
identically to :c:func:`!strncmp` except that it ignores the case.
|
||||
|
|
|
@ -83,7 +83,7 @@ Printing and clearing
|
|||
This utility function prints a warning message to ``sys.stderr`` when an
|
||||
exception has been set but it is impossible for the interpreter to actually
|
||||
raise the exception. It is used, for example, when an exception occurs in an
|
||||
:meth:`__del__` method.
|
||||
:meth:`~object.__del__` method.
|
||||
|
||||
The function is called with a single argument *obj* that identifies the context
|
||||
in which the unraisable exception occurred. If possible,
|
||||
|
@ -165,7 +165,7 @@ For convenience, some of these functions will always return a
|
|||
tuple object whose first item is the integer :c:data:`errno` value and whose
|
||||
second item is the corresponding error message (gotten from :c:func:`!strerror`),
|
||||
and then calls ``PyErr_SetObject(type, object)``. On Unix, when the
|
||||
:c:data:`errno` value is :c:macro:`EINTR`, indicating an interrupted system call,
|
||||
:c:data:`errno` value is :c:macro:`!EINTR`, indicating an interrupted system call,
|
||||
this calls :c:func:`PyErr_CheckSignals`, and if that set the error indicator,
|
||||
leaves it set to that. The function always returns ``NULL``, so a wrapper
|
||||
function around a system call can write ``return PyErr_SetFromErrno(type);``
|
||||
|
@ -177,7 +177,7 @@ For convenience, some of these functions will always return a
|
|||
Similar to :c:func:`PyErr_SetFromErrno`, with the additional behavior that if
|
||||
*filenameObject* is not ``NULL``, it is passed to the constructor of *type* as
|
||||
a third parameter. In the case of :exc:`OSError` exception,
|
||||
this is used to define the :attr:`filename` attribute of the
|
||||
this is used to define the :attr:`!filename` attribute of the
|
||||
exception instance.
|
||||
|
||||
|
||||
|
@ -200,12 +200,12 @@ For convenience, some of these functions will always return a
|
|||
.. c:function:: PyObject* PyErr_SetFromWindowsErr(int ierr)
|
||||
|
||||
This is a convenience function to raise :exc:`WindowsError`. If called with
|
||||
*ierr* of ``0``, the error code returned by a call to :c:func:`GetLastError`
|
||||
is used instead. It calls the Win32 function :c:func:`FormatMessage` to retrieve
|
||||
the Windows description of error code given by *ierr* or :c:func:`GetLastError`,
|
||||
*ierr* of ``0``, the error code returned by a call to :c:func:`!GetLastError`
|
||||
is used instead. It calls the Win32 function :c:func:`!FormatMessage` to retrieve
|
||||
the Windows description of error code given by *ierr* or :c:func:`!GetLastError`,
|
||||
then it constructs a tuple object whose first item is the *ierr* value and whose
|
||||
second item is the corresponding error message (gotten from
|
||||
:c:func:`FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
|
||||
:c:func:`!FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
|
||||
object)``. This function always returns ``NULL``.
|
||||
|
||||
.. availability:: Windows.
|
||||
|
@ -631,7 +631,7 @@ Signal Handling
|
|||
be interruptible by user requests (such as by pressing Ctrl-C).
|
||||
|
||||
.. note::
|
||||
The default Python signal handler for :c:macro:`SIGINT` raises the
|
||||
The default Python signal handler for :c:macro:`!SIGINT` raises the
|
||||
:exc:`KeyboardInterrupt` exception.
|
||||
|
||||
|
||||
|
@ -642,7 +642,7 @@ Signal Handling
|
|||
single: SIGINT
|
||||
single: KeyboardInterrupt (built-in exception)
|
||||
|
||||
Simulate the effect of a :c:macro:`SIGINT` signal arriving.
|
||||
Simulate the effect of a :c:macro:`!SIGINT` signal arriving.
|
||||
This is equivalent to ``PyErr_SetInterruptEx(SIGINT)``.
|
||||
|
||||
.. note::
|
||||
|
|
|
@ -25,8 +25,8 @@ include the :c:macro:`Py_TPFLAGS_HAVE_GC` and provide an implementation of the
|
|||
|
||||
Constructors for container types must conform to two rules:
|
||||
|
||||
#. The memory for the object must be allocated using :c:func:`PyObject_GC_New`
|
||||
or :c:func:`PyObject_GC_NewVar`.
|
||||
#. The memory for the object must be allocated using :c:macro:`PyObject_GC_New`
|
||||
or :c:macro:`PyObject_GC_NewVar`.
|
||||
|
||||
#. Once all the fields which may contain references to other containers are
|
||||
initialized, it must call :c:func:`PyObject_GC_Track`.
|
||||
|
@ -52,19 +52,19 @@ rules:
|
|||
class that implements the garbage collector protocol and the child class
|
||||
does *not* include the :c:macro:`Py_TPFLAGS_HAVE_GC` flag.
|
||||
|
||||
.. c:function:: TYPE* PyObject_GC_New(TYPE, PyTypeObject *type)
|
||||
.. c:macro:: PyObject_GC_New(TYPE, typeobj)
|
||||
|
||||
Analogous to :c:func:`PyObject_New` but for container objects with the
|
||||
Analogous to :c:macro:`PyObject_New` but for container objects with the
|
||||
:c:macro:`Py_TPFLAGS_HAVE_GC` flag set.
|
||||
|
||||
.. c:function:: TYPE* PyObject_GC_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
|
||||
.. c:macro:: PyObject_GC_NewVar(TYPE, typeobj, size)
|
||||
|
||||
Analogous to :c:func:`PyObject_NewVar` but for container objects with the
|
||||
Analogous to :c:macro:`PyObject_NewVar` but for container objects with the
|
||||
:c:macro:`Py_TPFLAGS_HAVE_GC` flag set.
|
||||
|
||||
.. c:function:: PyObject* PyUnstable_Object_GC_NewWithExtraData(PyTypeObject *type, size_t extra_size)
|
||||
|
||||
Analogous to :c:func:`PyObject_GC_New` but allocates *extra_size*
|
||||
Analogous to :c:macro:`PyObject_GC_New` but allocates *extra_size*
|
||||
bytes at the end of the object (at offset
|
||||
:c:member:`~PyTypeObject.tp_basicsize`).
|
||||
The allocated memory is initialized to zeros,
|
||||
|
@ -85,7 +85,7 @@ rules:
|
|||
|
||||
.. c:function:: TYPE* PyObject_GC_Resize(TYPE, PyVarObject *op, Py_ssize_t newsize)
|
||||
|
||||
Resize an object allocated by :c:func:`PyObject_NewVar`. Returns the
|
||||
Resize an object allocated by :c:macro:`PyObject_NewVar`. Returns the
|
||||
resized object or ``NULL`` on failure. *op* must not be tracked by the collector yet.
|
||||
|
||||
|
||||
|
@ -128,8 +128,8 @@ rules:
|
|||
|
||||
.. c:function:: void PyObject_GC_Del(void *op)
|
||||
|
||||
Releases memory allocated to an object using :c:func:`PyObject_GC_New` or
|
||||
:c:func:`PyObject_GC_NewVar`.
|
||||
Releases memory allocated to an object using :c:macro:`PyObject_GC_New` or
|
||||
:c:macro:`PyObject_GC_NewVar`.
|
||||
|
||||
|
||||
.. c:function:: void PyObject_GC_UnTrack(void *op)
|
||||
|
|
|
@ -135,10 +135,10 @@ Importing Modules
|
|||
The module's :attr:`__spec__` and :attr:`__loader__` will be set, if
|
||||
not set already, with the appropriate values. The spec's loader will
|
||||
be set to the module's ``__loader__`` (if set) and to an instance of
|
||||
:class:`SourceFileLoader` otherwise.
|
||||
:class:`~importlib.machinery.SourceFileLoader` otherwise.
|
||||
|
||||
The module's :attr:`__file__` attribute will be set to the code object's
|
||||
:attr:`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
|
||||
|
@ -225,7 +225,7 @@ Importing Modules
|
|||
|
||||
.. c:function:: PyObject* PyImport_GetImporter(PyObject *path)
|
||||
|
||||
Return a finder object for a :data:`sys.path`/:attr:`pkg.__path__` item
|
||||
Return a finder object for a :data:`sys.path`/:attr:`!pkg.__path__` item
|
||||
*path*, possibly by fetching it from the :data:`sys.path_importer_cache`
|
||||
dict. If it wasn't yet cached, traverse :data:`sys.path_hooks` until a hook
|
||||
is found that can handle the path item. Return ``None`` if no hook could;
|
||||
|
|
|
@ -25,7 +25,7 @@ The following functions can be safely called before Python is initialized:
|
|||
|
||||
* :c:func:`PyImport_AppendInittab`
|
||||
* :c:func:`PyImport_ExtendInittab`
|
||||
* :c:func:`PyInitFrozenExtensions`
|
||||
* :c:func:`!PyInitFrozenExtensions`
|
||||
* :c:func:`PyMem_SetAllocator`
|
||||
* :c:func:`PyMem_SetupDebugHooks`
|
||||
* :c:func:`PyObject_SetArenaAllocator`
|
||||
|
@ -157,7 +157,7 @@ to 1 and ``-bb`` sets :c:data:`Py_BytesWarningFlag` to 2.
|
|||
:c:member:`PyConfig.use_environment` should be used instead, see
|
||||
:ref:`Python Initialization Configuration <init-config>`.
|
||||
|
||||
Ignore all :envvar:`PYTHON*` environment variables, e.g.
|
||||
Ignore all :envvar:`!PYTHON*` environment variables, e.g.
|
||||
:envvar:`PYTHONPATH` and :envvar:`PYTHONHOME`, that might be set.
|
||||
|
||||
Set by the :option:`-E` and :option:`-I` options.
|
||||
|
@ -230,7 +230,7 @@ to 1 and ``-bb`` sets :c:data:`Py_BytesWarningFlag` to 2.
|
|||
:ref:`Python Initialization Configuration <init-config>`.
|
||||
|
||||
If the flag is non-zero, use :class:`io.FileIO` instead of
|
||||
:class:`WindowsConsoleIO` for :mod:`sys` standard streams.
|
||||
:class:`!io._WindowsConsoleIO` for :mod:`sys` standard streams.
|
||||
|
||||
Set to ``1`` if the :envvar:`PYTHONLEGACYWINDOWSSTDIO` environment
|
||||
variable is set to a non-empty string.
|
||||
|
@ -401,7 +401,7 @@ Initializing and finalizing the interpreter
|
|||
the application.
|
||||
|
||||
**Bugs and caveats:** The destruction of modules and objects in modules is done
|
||||
in random order; this may cause destructors (:meth:`__del__` methods) to fail
|
||||
in random order; this may cause destructors (:meth:`~object.__del__` methods) to fail
|
||||
when they depend on other objects (even functions) or modules. Dynamically
|
||||
loaded extension modules loaded by Python are not unloaded. Small amounts of
|
||||
memory allocated by the Python interpreter may not be freed (if you find a leak,
|
||||
|
@ -485,12 +485,12 @@ Process-wide parameters
|
|||
interpreter will change the contents of this storage.
|
||||
|
||||
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
|
||||
:c:expr:`wchar_*` string.
|
||||
:c:expr:`wchar_t *` string.
|
||||
|
||||
.. deprecated:: 3.11
|
||||
|
||||
|
||||
.. c:function:: wchar* Py_GetProgramName()
|
||||
.. c:function:: wchar_t* Py_GetProgramName()
|
||||
|
||||
.. index:: single: Py_SetProgramName()
|
||||
|
||||
|
@ -981,7 +981,7 @@ the fork, and releasing them afterwards. In addition, it resets any
|
|||
:ref:`lock-objects` in the child. When extending or embedding Python, there
|
||||
is no way to inform Python of additional (non-Python) locks that need to be
|
||||
acquired before or reset after a fork. OS facilities such as
|
||||
:c:func:`pthread_atfork` would need to be used to accomplish the same thing.
|
||||
:c:func:`!pthread_atfork` would need to be used to accomplish the same thing.
|
||||
Additionally, when extending or embedding Python, calling :c:func:`fork`
|
||||
directly rather than through :func:`os.fork` (and returning to or calling
|
||||
into Python) may result in a deadlock by one of Python's internal locks
|
||||
|
@ -1087,7 +1087,7 @@ code, or when embedding the Python interpreter:
|
|||
.. note::
|
||||
Calling this function from a thread when the runtime is finalizing
|
||||
will terminate the thread, even if the thread was not created by Python.
|
||||
You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
check if the interpreter is in process of being finalized before calling
|
||||
this function to avoid unwanted termination.
|
||||
|
||||
|
@ -1133,7 +1133,7 @@ with sub-interpreters:
|
|||
.. note::
|
||||
Calling this function from a thread when the runtime is finalizing
|
||||
will terminate the thread, even if the thread was not created by Python.
|
||||
You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
check if the interpreter is in process of being finalized before calling
|
||||
this function to avoid unwanted termination.
|
||||
|
||||
|
@ -1415,7 +1415,7 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
|
|||
.. note::
|
||||
Calling this function from a thread when the runtime is finalizing
|
||||
will terminate the thread, even if the thread was not created by Python.
|
||||
You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
|
||||
check if the interpreter is in process of being finalized before calling
|
||||
this function to avoid unwanted termination.
|
||||
|
||||
|
|
|
@ -871,7 +871,7 @@ PyConfig
|
|||
.. c:member:: int legacy_windows_stdio
|
||||
|
||||
If non-zero, use :class:`io.FileIO` instead of
|
||||
:class:`io.WindowsConsoleIO` for :data:`sys.stdin`, :data:`sys.stdout`
|
||||
:class:`!io._WindowsConsoleIO` for :data:`sys.stdin`, :data:`sys.stdout`
|
||||
and :data:`sys.stderr`.
|
||||
|
||||
Set to ``1`` if the :envvar:`PYTHONLEGACYWINDOWSSTDIO` environment
|
||||
|
@ -1120,7 +1120,7 @@ PyConfig
|
|||
|
||||
Set to ``0`` by the :option:`-S` command line option.
|
||||
|
||||
:data:`sys.flags.no_site` is set to the inverted value of
|
||||
:data:`sys.flags.no_site <sys.flags>` is set to the inverted value of
|
||||
:c:member:`~PyConfig.site_import`.
|
||||
|
||||
Default: ``1``.
|
||||
|
|
|
@ -136,7 +136,7 @@ need to be held.
|
|||
|
||||
The :ref:`default raw memory allocator <default-memory-allocators>` uses
|
||||
the following functions: :c:func:`malloc`, :c:func:`calloc`, :c:func:`realloc`
|
||||
and :c:func:`free`; call ``malloc(1)`` (or ``calloc(1, 1)``) when requesting
|
||||
and :c:func:`!free`; call ``malloc(1)`` (or ``calloc(1, 1)``) when requesting
|
||||
zero bytes.
|
||||
|
||||
.. versionadded:: 3.4
|
||||
|
@ -264,14 +264,14 @@ The following type-oriented macros are provided for convenience. Note that
|
|||
*TYPE* refers to any C type.
|
||||
|
||||
|
||||
.. c:function:: TYPE* PyMem_New(TYPE, size_t n)
|
||||
.. c:macro:: PyMem_New(TYPE, n)
|
||||
|
||||
Same as :c:func:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes of
|
||||
memory. Returns a pointer cast to :c:expr:`TYPE*`. The memory will not have
|
||||
been initialized in any way.
|
||||
|
||||
|
||||
.. c:function:: TYPE* PyMem_Resize(void *p, TYPE, size_t n)
|
||||
.. c:macro:: PyMem_Resize(p, TYPE, n)
|
||||
|
||||
Same as :c:func:`PyMem_Realloc`, but the memory block is resized to ``(n *
|
||||
sizeof(TYPE))`` bytes. Returns a pointer cast to :c:expr:`TYPE*`. On return,
|
||||
|
@ -423,7 +423,7 @@ Customize Memory Allocators
|
|||
+----------------------------------------------------------+---------------------------------------+
|
||||
|
||||
.. versionchanged:: 3.5
|
||||
The :c:type:`PyMemAllocator` structure was renamed to
|
||||
The :c:type:`!PyMemAllocator` structure was renamed to
|
||||
:c:type:`PyMemAllocatorEx` and a new ``calloc`` field was added.
|
||||
|
||||
|
||||
|
@ -627,8 +627,8 @@ with a fixed size of 256 KiB. It falls back to :c:func:`PyMem_RawMalloc` and
|
|||
|
||||
The arena allocator uses the following functions:
|
||||
|
||||
* :c:func:`VirtualAlloc` and :c:func:`VirtualFree` on Windows,
|
||||
* :c:func:`mmap` and :c:func:`munmap` if available,
|
||||
* :c:func:`!VirtualAlloc` and :c:func:`!VirtualFree` on Windows,
|
||||
* :c:func:`!mmap` and :c:func:`!munmap` if available,
|
||||
* :c:func:`malloc` and :c:func:`free` otherwise.
|
||||
|
||||
This allocator is disabled if Python is configured with the
|
||||
|
@ -732,8 +732,8 @@ allocators operating on different heaps. ::
|
|||
free(buf1); /* Fatal -- should be PyMem_Del() */
|
||||
|
||||
In addition to the functions aimed at handling raw memory blocks from the Python
|
||||
heap, objects in Python are allocated and released with :c:func:`PyObject_New`,
|
||||
:c:func:`PyObject_NewVar` and :c:func:`PyObject_Del`.
|
||||
heap, objects in Python are allocated and released with :c:macro:`PyObject_New`,
|
||||
:c:macro:`PyObject_NewVar` and :c:func:`PyObject_Del`.
|
||||
|
||||
These will be explained in the next chapter on defining and implementing new
|
||||
object types in C.
|
||||
|
|
|
@ -282,7 +282,7 @@ An alternate way to specify extensions is to request "multi-phase initialization
|
|||
Extension modules created this way behave more like Python modules: the
|
||||
initialization is split between the *creation phase*, when the module object
|
||||
is created, and the *execution phase*, when it is populated.
|
||||
The distinction is similar to the :py:meth:`__new__` and :py:meth:`__init__` methods
|
||||
The distinction is similar to the :py:meth:`!__new__` and :py:meth:`!__init__` methods
|
||||
of classes.
|
||||
|
||||
Unlike modules created using single-phase initialization, these modules are not
|
||||
|
@ -293,7 +293,7 @@ By default, multiple modules created from the same definition should be
|
|||
independent: changes to one should not affect the others.
|
||||
This means that all state should be specific to the module object (using e.g.
|
||||
using :c:func:`PyModule_GetState`), or its contents (such as the module's
|
||||
:attr:`__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
|
||||
:attr:`~object.__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
|
||||
|
||||
All modules created using multi-phase initialization are expected to support
|
||||
:ref:`sub-interpreters <sub-interpreter-support>`. Making sure multiple modules
|
||||
|
@ -555,7 +555,7 @@ state:
|
|||
``NULL``-terminated. Return ``-1`` on error, ``0`` on success.
|
||||
|
||||
|
||||
.. c:function:: int PyModule_AddIntMacro(PyObject *module, macro)
|
||||
.. c:macro:: PyModule_AddIntMacro(module, macro)
|
||||
|
||||
Add an int constant to *module*. The name and the value are taken from
|
||||
*macro*. For example ``PyModule_AddIntMacro(module, AF_INET)`` adds the int
|
||||
|
@ -563,7 +563,7 @@ state:
|
|||
Return ``-1`` on error, ``0`` on success.
|
||||
|
||||
|
||||
.. c:function:: int PyModule_AddStringMacro(PyObject *module, macro)
|
||||
.. c:macro:: PyModule_AddStringMacro(module, macro)
|
||||
|
||||
Add a string constant to *module*.
|
||||
|
||||
|
|
|
@ -122,7 +122,7 @@ or :class:`frozenset` or instances of their subtypes.
|
|||
.. c:function:: int PySet_Contains(PyObject *anyset, PyObject *key)
|
||||
|
||||
Return ``1`` if found, ``0`` if not found, and ``-1`` if an error is encountered. Unlike
|
||||
the Python :meth:`__contains__` method, this function does not automatically
|
||||
the Python :meth:`~object.__contains__` method, this function does not automatically
|
||||
convert unhashable sets into temporary frozensets. Raise a :exc:`TypeError` if
|
||||
the *key* is unhashable. Raise :exc:`PyExc_SystemError` if *anyset* is not a
|
||||
:class:`set`, :class:`frozenset`, or an instance of a subtype.
|
||||
|
|
|
@ -393,7 +393,7 @@ definition with the same method name.
|
|||
*METH_COEXIST*, the default is to skip repeated definitions. Since slot
|
||||
wrappers are loaded before the method table, the existence of a
|
||||
*sq_contains* slot, for example, would generate a wrapped method named
|
||||
:meth:`__contains__` and preclude the loading of a corresponding
|
||||
:meth:`~object.__contains__` and preclude the loading of a corresponding
|
||||
PyCFunction with the same name. With the flag defined, the PyCFunction
|
||||
will be loaded in place of the wrapper object and will co-exist with the
|
||||
slot. This is helpful because calls to PyCFunctions are optimized more
|
||||
|
|
|
@ -414,7 +414,7 @@ Process Control
|
|||
This function should only be invoked when a condition is detected that would
|
||||
make it dangerous to continue using the Python interpreter; e.g., when the
|
||||
object administration appears to be corrupted. On Unix, the standard C library
|
||||
function :c:func:`abort` is called which will attempt to produce a :file:`core`
|
||||
function :c:func:`!abort` is called which will attempt to produce a :file:`core`
|
||||
file.
|
||||
|
||||
The ``Py_FatalError()`` function is replaced with a macro which logs
|
||||
|
|
|
@ -579,7 +579,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
|
|||
name, followed by a dot, followed by the type name; for built-in types, it
|
||||
should be just the type name. If the module is a submodule of a package, the
|
||||
full package name is part of the full module name. For example, a type named
|
||||
:class:`T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P`
|
||||
:class:`!T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P`
|
||||
should have the :c:member:`~PyTypeObject.tp_name` initializer ``"P.Q.M.T"``.
|
||||
|
||||
For :ref:`dynamically allocated type objects <heap-types>`,
|
||||
|
@ -673,9 +673,9 @@ and :c:data:`PyType_Type` effectively act as defaults.)
|
|||
permissible to call the object deallocator directly instead of via
|
||||
:c:member:`~PyTypeObject.tp_free`. The object deallocator should be the one used to allocate the
|
||||
instance; this is normally :c:func:`PyObject_Del` if the instance was allocated
|
||||
using :c:func:`PyObject_New` or :c:func:`PyObject_VarNew`, or
|
||||
using :c:macro:`PyObject_New` or :c:macro:`PyObject_NewVar`, or
|
||||
:c:func:`PyObject_GC_Del` if the instance was allocated using
|
||||
:c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar`.
|
||||
:c:macro:`PyObject_GC_New` or :c:macro:`PyObject_GC_NewVar`.
|
||||
|
||||
If the type supports garbage collection (has the :c:macro:`Py_TPFLAGS_HAVE_GC`
|
||||
flag bit set), the destructor should call :c:func:`PyObject_GC_UnTrack`
|
||||
|
@ -1092,7 +1092,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
|
|||
.. c:macro:: Py_TPFLAGS_HAVE_GC
|
||||
|
||||
This bit is set when the object supports garbage collection. If this bit
|
||||
is set, instances must be created using :c:func:`PyObject_GC_New` and
|
||||
is set, instances must be created using :c:macro:`PyObject_GC_New` and
|
||||
destroyed using :c:func:`PyObject_GC_Del`. More information in section
|
||||
:ref:`supporting-cycle-detection`. This bit also implies that the
|
||||
GC-related fields :c:member:`~PyTypeObject.tp_traverse` and :c:member:`~PyTypeObject.tp_clear` are present in
|
||||
|
@ -1180,7 +1180,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
|
|||
|
||||
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
|
||||
:c:expr:`Py_TYPE(obj)->tp_basicsize` (which may be different in each
|
||||
``Py_TYPE(obj)->tp_basicsize`` (which may be different in each
|
||||
subclass).
|
||||
|
||||
When setting this flag, be sure that all superclasses either
|
||||
|
|
|
@ -608,7 +608,7 @@ APIs:
|
|||
Py_ssize_t how_many)
|
||||
|
||||
Copy characters from one Unicode object into another. This function performs
|
||||
character conversion when necessary and falls back to :c:func:`memcpy` if
|
||||
character conversion when necessary and falls back to :c:func:`!memcpy` if
|
||||
possible. Returns ``-1`` and sets an exception on error, otherwise returns
|
||||
the number of copied characters.
|
||||
|
||||
|
@ -721,7 +721,7 @@ system.
|
|||
.. c:function:: PyObject* PyUnicode_DecodeLocale(const char *str, const char *errors)
|
||||
|
||||
Similar to :c:func:`PyUnicode_DecodeLocaleAndSize`, but compute the string
|
||||
length using :c:func:`strlen`.
|
||||
length using :c:func:`!strlen`.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
@ -879,7 +879,7 @@ wchar_t Support
|
|||
most C functions. If *size* is ``NULL`` and the :c:expr:`wchar_t*` string
|
||||
contains null characters a :exc:`ValueError` is raised.
|
||||
|
||||
Returns a buffer allocated by :c:func:`PyMem_New` (use
|
||||
Returns a buffer allocated by :c:macro:`PyMem_New` (use
|
||||
:c:func:`PyMem_Free` to free it) on success. On error, returns ``NULL``
|
||||
and *\*size* is undefined. Raises a :exc:`MemoryError` if memory allocation
|
||||
is failed.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue