mirror of
https://github.com/python/cpython
synced 2024-09-05 00:05:39 +00:00
gh-107298: Fix numerous ref errors and typos in the C API docs (GH-108258)
This commit is contained in:
Serhiy Storchaka
GitHub
parent
c556f9a3c9
commit
d7202e4879
|
|
@ -222,17 +222,21 @@ For convenience, some of these functions will always return a
|
|||
|
||||
.. c:function:: PyObject* PyErr_SetFromWindowsErrWithFilename(int ierr, const char *filename)
|
||||
|
||||
Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, but the
|
||||
filename is given as a C string. *filename* is decoded from the filesystem
|
||||
encoding (:func:`os.fsdecode`).
|
||||
Similar to :c:func:`PyErr_SetFromWindowsErr`, with the additional behavior
|
||||
that if *filename* is not ``NULL``, it is decoded from the filesystem
|
||||
encoding (:func:`os.fsdecode`) and passed to the constructor of
|
||||
:exc:`OSError` as a third parameter to be used to define the
|
||||
:attr:`!filename` attribute of the exception instance.
|
||||
|
||||
.. availability:: Windows.
|
||||
|
||||
|
||||
.. c:function:: PyObject* PyErr_SetExcFromWindowsErrWithFilenameObject(PyObject *type, int ierr, PyObject *filename)
|
||||
|
||||
Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, with an
|
||||
additional parameter specifying the exception type to be raised.
|
||||
Similar to :c:func:`PyErr_SetExcFromWindowsErr`, with the additional behavior
|
||||
that if *filename* is not ``NULL``, it is passed to the constructor of
|
||||
:exc:`OSError` as a third parameter to be used to define the
|
||||
:attr:`!filename` attribute of the exception instance.
|
||||
|
||||
.. availability:: Windows.
|
||||
|
||||
|
|
|
|||
|
|
@ -82,6 +82,8 @@ PyWideStringList
|
|||
If *length* is non-zero, *items* must be non-``NULL`` and all strings must be
|
||||
non-``NULL``.
|
||||
|
||||
.. c:namespace:: NULL
|
||||
|
||||
Methods:
|
||||
|
||||
.. c:function:: PyStatus PyWideStringList_Append(PyWideStringList *list, const wchar_t *item)
|
||||
|
|
@ -101,6 +103,8 @@ PyWideStringList
|
|||
|
||||
Python must be preinitialized to call this function.
|
||||
|
||||
.. c:namespace:: PyWideStringList
|
||||
|
||||
Structure fields:
|
||||
|
||||
.. c:member:: Py_ssize_t length
|
||||
|
|
|
|||
|
|
@ -338,6 +338,7 @@ The available slot types are:
|
|||
The *value* pointer of this slot must point to a function of the signature:
|
||||
|
||||
.. c:function:: PyObject* create_module(PyObject *spec, PyModuleDef *def)
|
||||
:noindex:
|
||||
|
||||
The function receives a :py:class:`~importlib.machinery.ModuleSpec`
|
||||
instance, as defined in :PEP:`451`, and the module definition.
|
||||
|
|
@ -372,6 +373,7 @@ The available slot types are:
|
|||
The signature of the function is:
|
||||
|
||||
.. c:function:: int exec_module(PyObject* module)
|
||||
:noindex:
|
||||
|
||||
If multiple ``Py_mod_exec`` slots are specified, they are processed in the
|
||||
order they appear in the *m_slots* array.
|
||||
|
|
@ -380,6 +382,8 @@ The available slot types are:
|
|||
|
||||
Specifies one of the following values:
|
||||
|
||||
.. c:namespace:: NULL
|
||||
|
||||
.. c:macro:: Py_MOD_MULTIPLE_INTERPRETERS_NOT_SUPPORTED
|
||||
|
||||
The module does not support being imported in subinterpreters.
|
||||
|
|
|
|||
|
|
@ -1292,7 +1292,7 @@ the user settings on the machine running the codec.
|
|||
|
||||
Encode the Unicode object using the specified code page and return a Python
|
||||
bytes object. Return ``NULL`` if an exception was raised by the codec. Use
|
||||
:c:macro:`CP_ACP` code page to get the MBCS encoder.
|
||||
:c:macro:`!CP_ACP` code page to get the MBCS encoder.
|
||||
|
||||
.. versionadded:: 3.3
|
||||
|
||||
|
|
|
|||
|
|
@ -298,7 +298,7 @@ have an associated doc string simply by providing the text in the table. An
|
|||
application can use the introspection API to retrieve the descriptor from the
|
||||
class object, and get the doc string using its :attr:`__doc__` attribute.
|
||||
|
||||
As with the :c:member:`~PyTypeObject.tp_methods` table, a sentinel entry with a :c:member:`~PyMethodDef.name` value
|
||||
As with the :c:member:`~PyTypeObject.tp_methods` table, a sentinel entry with a :c:member:`~PyMethodDef.ml_name` value
|
||||
of ``NULL`` is required.
|
||||
|
||||
.. XXX Descriptors need to be explained in more detail somewhere, but not here.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@ Doc/c-api/structures.rst
|
|||
Doc/c-api/sys.rst
|
||||
Doc/c-api/type.rst
|
||||
Doc/c-api/typeobj.rst
|
||||
Doc/c-api/unicode.rst
|
||||
Doc/extending/extending.rst
|
||||
Doc/extending/newtypes.rst
|
||||
Doc/glossary.rst
|
||||
|
|
|
|||
|
|
@ -1078,17 +1078,17 @@ code, none of the changes described here will affect you very much.
|
|||
|
||||
To upgrade an extension module to the new API, perform the following steps:
|
||||
|
||||
* Rename :c:func:`Py_TPFLAGS_GC` to :c:func:`PyTPFLAGS_HAVE_GC`.
|
||||
* Rename :c:macro:`!Py_TPFLAGS_GC` to :c:macro:`Py_TPFLAGS_HAVE_GC`.
|
||||
|
||||
* Use :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar` to allocate
|
||||
objects, and :c:func:`PyObject_GC_Del` to deallocate them.
|
||||
|
||||
* Rename :c:func:`PyObject_GC_Init` to :c:func:`PyObject_GC_Track` and
|
||||
:c:func:`PyObject_GC_Fini` to :c:func:`PyObject_GC_UnTrack`.
|
||||
* Rename :c:func:`!PyObject_GC_Init` to :c:func:`PyObject_GC_Track` and
|
||||
:c:func:`!PyObject_GC_Fini` to :c:func:`PyObject_GC_UnTrack`.
|
||||
|
||||
* Remove :c:func:`PyGC_HEAD_SIZE` from object size calculations.
|
||||
* Remove :c:macro:`!PyGC_HEAD_SIZE` from object size calculations.
|
||||
|
||||
* Remove calls to :c:func:`PyObject_AS_GC` and :c:func:`PyObject_FROM_GC`.
|
||||
* Remove calls to :c:func:`!PyObject_AS_GC` and :c:func:`!PyObject_FROM_GC`.
|
||||
|
||||
* A new ``et`` format sequence was added to :c:func:`PyArg_ParseTuple`; ``et``
|
||||
takes both a parameter and an encoding name, and converts the parameter to the
|
||||
|
|
@ -1219,7 +1219,7 @@ Some of the more notable changes are:
|
|||
operator, but these features were rarely used and therefore buggy. The
|
||||
:meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step`
|
||||
attributes are also being deprecated. At the C level, the fourth argument to
|
||||
the :c:func:`PyRange_New` function, ``repeat``, has also been deprecated.
|
||||
the :c:func:`!PyRange_New` function, ``repeat``, has also been deprecated.
|
||||
|
||||
* There were a bunch of patches to the dictionary implementation, mostly to fix
|
||||
potential core dumps if a dictionary contains objects that sneakily changed
|
||||
|
|
|
|||
|
|
@ -1897,7 +1897,7 @@ Changes to Python's build process and to the C API include:
|
|||
but will also mean that you can't get help for Python's built-ins. (Contributed
|
||||
by Gustavo Niemeyer.)
|
||||
|
||||
* The :c:func:`PyArg_NoArgs` macro is now deprecated, and code that uses it
|
||||
* The :c:func:`!PyArg_NoArgs` macro is now deprecated, and code that uses it
|
||||
should be changed. For Python 2.2 and later, the method definition table can
|
||||
specify the :c:macro:`METH_NOARGS` flag, signalling that there are no arguments,
|
||||
and the argument checking can then be removed. If compatibility with pre-2.2
|
||||
|
|
|
|||
|
|
@ -1468,7 +1468,7 @@ Some of the changes to Python's build process and to the C API are:
|
|||
*X* is a NaN. (Contributed by Tim Peters.)
|
||||
|
||||
* C code can avoid unnecessary locking by using the new
|
||||
:c:func:`PyEval_ThreadsInitialized` function to tell if any thread operations
|
||||
:c:func:`!PyEval_ThreadsInitialized` function to tell if any thread operations
|
||||
have been performed. If this function returns false, no lock operations are
|
||||
needed. (Contributed by Nick Coghlan.)
|
||||
|
||||
|
|
|
|||
|
|
@ -2119,9 +2119,9 @@ Changes to Python's build process and to the C API include:
|
|||
the various AST nodes in :file:`Parser/Python.asdl`. A Python script reads this
|
||||
file and generates a set of C structure definitions in
|
||||
:file:`Include/Python-ast.h`. The :c:func:`PyParser_ASTFromString` and
|
||||
:c:func:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take
|
||||
:c:func:`!PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take
|
||||
Python source as input and return the root of an AST representing the contents.
|
||||
This AST can then be turned into a code object by :c:func:`PyAST_Compile`. For
|
||||
This AST can then be turned into a code object by :c:func:`!PyAST_Compile`. For
|
||||
more information, read the source code, and then ask questions on python-dev.
|
||||
|
||||
The AST code was developed under Jeremy Hylton's management, and implemented by
|
||||
|
|
@ -2172,7 +2172,7 @@ Changes to Python's build process and to the C API include:
|
|||
``Py_LOCAL(type)`` declares the function as returning a value of the
|
||||
specified *type* and uses a fast-calling qualifier.
|
||||
``Py_LOCAL_INLINE(type)`` does the same thing and also requests the
|
||||
function be inlined. If :c:func:`PY_LOCAL_AGGRESSIVE` is defined before
|
||||
function be inlined. If macro :c:macro:`!PY_LOCAL_AGGRESSIVE` is defined before
|
||||
:file:`python.h` is included, a set of more aggressive optimizations are enabled
|
||||
for the module; you should benchmark the results to find out if these
|
||||
optimizations actually make the code faster. (Contributed by Fredrik Lundh at
|
||||
|
|
@ -2181,7 +2181,7 @@ Changes to Python's build process and to the C API include:
|
|||
* ``PyErr_NewException(name, base, dict)`` can now accept a tuple of base
|
||||
classes as its *base* argument. (Contributed by Georg Brandl.)
|
||||
|
||||
* The :c:func:`PyErr_Warn` function for issuing warnings is now deprecated in
|
||||
* The :c:func:`!PyErr_Warn` function for issuing warnings is now deprecated in
|
||||
favour of ``PyErr_WarnEx(category, message, stacklevel)`` which lets you
|
||||
specify the number of stack frames separating this function and the caller. A
|
||||
*stacklevel* of 1 is the function calling :c:func:`PyErr_WarnEx`, 2 is the
|
||||
|
|
@ -2191,7 +2191,7 @@ Changes to Python's build process and to the C API include:
|
|||
compiled with a C++ compiler without errors. (Implemented by Anthony Baxter,
|
||||
Martin von Löwis, Skip Montanaro.)
|
||||
|
||||
* The :c:func:`PyRange_New` function was removed. It was never documented, never
|
||||
* The :c:func:`!PyRange_New` function was removed. It was never documented, never
|
||||
used in the core code, and had dangerously lax error checking. In the unlikely
|
||||
case that your extensions were using it, you can replace it by something like
|
||||
the following::
|
||||
|
|
|
|||
|
|
@ -977,7 +977,7 @@ can be used to include Unicode characters::
|
|||
print len(s) # 12 Unicode characters
|
||||
|
||||
At the C level, Python 3.0 will rename the existing 8-bit
|
||||
string type, called :c:type:`PyStringObject` in Python 2.x,
|
||||
string type, called :c:type:`!PyStringObject` in Python 2.x,
|
||||
to :c:type:`PyBytesObject`. Python 2.6 uses ``#define``
|
||||
to support using the names :c:func:`PyBytesObject`,
|
||||
:c:func:`PyBytes_Check`, :c:func:`PyBytes_FromStringAndSize`,
|
||||
|
|
@ -3012,11 +3012,11 @@ Changes to Python's build process and to the C API include:
|
|||
bug occurred if one thread closed a file object while another thread
|
||||
was reading from or writing to the object. In 2.6 file objects
|
||||
have a reference count, manipulated by the
|
||||
:c:func:`PyFile_IncUseCount` and :c:func:`PyFile_DecUseCount`
|
||||
:c:func:`!PyFile_IncUseCount` and :c:func:`!PyFile_DecUseCount`
|
||||
functions. File objects can't be closed unless the reference count
|
||||
is zero. :c:func:`PyFile_IncUseCount` should be called while the GIL
|
||||
is zero. :c:func:`!PyFile_IncUseCount` should be called while the GIL
|
||||
is still held, before carrying out an I/O operation using the
|
||||
``FILE *`` pointer, and :c:func:`PyFile_DecUseCount` should be called
|
||||
``FILE *`` pointer, and :c:func:`!PyFile_DecUseCount` should be called
|
||||
immediately after the GIL is re-acquired.
|
||||
(Contributed by Antoine Pitrou and Gregory P. Smith.)
|
||||
|
||||
|
|
|
|||
|
|
@ -2152,7 +2152,7 @@ Changes to Python's build process and to the C API include:
|
|||
|
||||
* New function: stemming from the rewrite of string-to-float conversion,
|
||||
a new :c:func:`PyOS_string_to_double` function was added. The old
|
||||
:c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof` functions
|
||||
:c:func:`!PyOS_ascii_strtod` and :c:func:`!PyOS_ascii_atof` functions
|
||||
are now deprecated.
|
||||
|
||||
* New function: :c:func:`PySys_SetArgvEx` sets the value of
|
||||
|
|
@ -2195,13 +2195,13 @@ Changes to Python's build process and to the C API include:
|
|||
|
||||
.. XXX these macros don't seem to be described in the c-api docs.
|
||||
|
||||
* Removed function: :c:macro:`PyEval_CallObject` is now only available
|
||||
* Removed function: :c:func:`!PyEval_CallObject` is now only available
|
||||
as a macro. A function version was being kept around to preserve
|
||||
ABI linking compatibility, but that was in 1997; it can certainly be
|
||||
deleted by now. (Removed by Antoine Pitrou; :issue:`8276`.)
|
||||
|
||||
* New format codes: the :c:func:`PyFormat_FromString`,
|
||||
:c:func:`PyFormat_FromStringV`, and :c:func:`PyErr_Format` functions now
|
||||
* New format codes: the :c:func:`!PyString_FromFormat`,
|
||||
:c:func:`!PyString_FromFormatV`, and :c:func:`PyErr_Format` functions now
|
||||
accept ``%lld`` and ``%llu`` format codes for displaying
|
||||
C's :c:expr:`long long` types.
|
||||
(Contributed by Mark Dickinson; :issue:`7228`.)
|
||||
|
|
@ -2540,7 +2540,7 @@ For C extensions:
|
|||
instead of triggering a :exc:`DeprecationWarning` (:issue:`5080`).
|
||||
|
||||
* Use the new :c:func:`PyOS_string_to_double` function instead of the old
|
||||
:c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof` functions,
|
||||
:c:func:`!PyOS_ascii_strtod` and :c:func:`!PyOS_ascii_atof` functions,
|
||||
which are now deprecated.
|
||||
|
||||
For applications that embed Python:
|
||||
|
|
|
|||
|
|
@ -865,8 +865,8 @@ to the C API.
|
|||
|
||||
* No more C API support for restricted execution.
|
||||
|
||||
* :c:func:`PyNumber_Coerce`, :c:func:`PyNumber_CoerceEx`,
|
||||
:c:func:`PyMember_Get`, and :c:func:`PyMember_Set` C APIs are removed.
|
||||
* :c:func:`!PyNumber_Coerce`, :c:func:`!PyNumber_CoerceEx`,
|
||||
:c:func:`!PyMember_Get`, and :c:func:`!PyMember_Set` C APIs are removed.
|
||||
|
||||
* New C API :c:func:`PyImport_ImportModuleNoBlock`, works like
|
||||
:c:func:`PyImport_ImportModule` but won't block on the import lock
|
||||
|
|
|
|||
|
|
@ -501,12 +501,12 @@ Changes to Python's build process and to the C API include:
|
|||
|
||||
(Contributed by Mark Dickinson and Lisandro Dalcrin; :issue:`5175`.)
|
||||
|
||||
* Deprecated :c:func:`PyNumber_Int`. Use :c:func:`PyNumber_Long` instead.
|
||||
* Deprecated :c:func:`!PyNumber_Int`. Use :c:func:`PyNumber_Long` instead.
|
||||
|
||||
(Contributed by Mark Dickinson; :issue:`4910`.)
|
||||
|
||||
* Added a new :c:func:`PyOS_string_to_double` function to replace the
|
||||
deprecated functions :c:func:`PyOS_ascii_strtod` and :c:func:`PyOS_ascii_atof`.
|
||||
deprecated functions :c:func:`!PyOS_ascii_strtod` and :c:func:`!PyOS_ascii_atof`.
|
||||
|
||||
(Contributed by Mark Dickinson; :issue:`5914`.)
|
||||
|
||||
|
|
|
|||
|
|
@ -1819,8 +1819,8 @@ Removed
|
|||
into their code.
|
||||
(Contributed by Dong-hee Na and Terry J. Reedy in :issue:`42299`.)
|
||||
|
||||
* Removed the :c:func:`PyModule_GetWarningsModule` function that was useless
|
||||
now due to the _warnings module was converted to a builtin module in 2.6.
|
||||
* Removed the :c:func:`!PyModule_GetWarningsModule` function that was useless
|
||||
now due to the :mod:`!_warnings` module was converted to a builtin module in 2.6.
|
||||
(Contributed by Hai Shi in :issue:`42599`.)
|
||||
|
||||
* Remove deprecated aliases to :ref:`collections-abstract-base-classes` from
|
||||
|
|
|
|||
|
|
@ -2216,7 +2216,7 @@ New Features
|
|||
* :c:func:`PyBuffer_SizeFromFormat`
|
||||
* :c:func:`PyBuffer_ToContiguous`
|
||||
* :c:func:`PyBuffer_FromContiguous`
|
||||
* :c:func:`PyBuffer_CopyData`
|
||||
* :c:func:`PyObject_CopyData`
|
||||
* :c:func:`PyBuffer_IsContiguous`
|
||||
* :c:func:`PyBuffer_FillContiguousStrides`
|
||||
* :c:func:`PyBuffer_FillInfo`
|
||||
|
|
@ -2562,18 +2562,18 @@ Deprecated
|
|||
|
||||
* Deprecate the following functions to configure the Python initialization:
|
||||
|
||||
* :c:func:`PySys_AddWarnOptionUnicode`
|
||||
* :c:func:`PySys_AddWarnOption`
|
||||
* :c:func:`PySys_AddXOption`
|
||||
* :c:func:`PySys_HasWarnOptions`
|
||||
* :c:func:`PySys_SetArgvEx`
|
||||
* :c:func:`PySys_SetArgv`
|
||||
* :c:func:`PySys_SetPath`
|
||||
* :c:func:`Py_SetPath`
|
||||
* :c:func:`Py_SetProgramName`
|
||||
* :c:func:`Py_SetPythonHome`
|
||||
* :c:func:`Py_SetStandardStreamEncoding`
|
||||
* :c:func:`_Py_SetProgramFullPath`
|
||||
* :c:func:`!PySys_AddWarnOptionUnicode`
|
||||
* :c:func:`!PySys_AddWarnOption`
|
||||
* :c:func:`!PySys_AddXOption`
|
||||
* :c:func:`!PySys_HasWarnOptions`
|
||||
* :c:func:`!PySys_SetArgvEx`
|
||||
* :c:func:`!PySys_SetArgv`
|
||||
* :c:func:`!PySys_SetPath`
|
||||
* :c:func:`!Py_SetPath`
|
||||
* :c:func:`!Py_SetProgramName`
|
||||
* :c:func:`!Py_SetPythonHome`
|
||||
* :c:func:`!Py_SetStandardStreamEncoding`
|
||||
* :c:func:`!_Py_SetProgramFullPath`
|
||||
|
||||
Use the new :c:type:`PyConfig` API of the :ref:`Python Initialization Configuration
|
||||
<init-config>` instead (:pep:`587`).
|
||||
|
|
|
|||
|
|
@ -2569,7 +2569,7 @@ Changes to Python's build process and to the C API include:
|
|||
to set :data:`sys.argv` without also modifying :data:`sys.path`
|
||||
(:issue:`5753`).
|
||||
|
||||
* :c:macro:`PyEval_CallObject` is now only available in macro form. The
|
||||
* :c:func:`!PyEval_CallObject` is now only available in macro form. The
|
||||
function declaration, which was kept for backwards compatibility reasons, is
|
||||
now removed -- the macro was introduced in 1997 (:issue:`8276`).
|
||||
|
||||
|
|
@ -2731,15 +2731,15 @@ require changes to your code:
|
|||
|
||||
(Contributed by Antoine Pitrou, :issue:`10272`.)
|
||||
|
||||
* The misleading functions :c:func:`PyEval_AcquireLock()` and
|
||||
:c:func:`PyEval_ReleaseLock()` have been officially deprecated. The
|
||||
thread-state aware APIs (such as :c:func:`PyEval_SaveThread()`
|
||||
and :c:func:`PyEval_RestoreThread()`) should be used instead.
|
||||
* The misleading functions :c:func:`!PyEval_AcquireLock` and
|
||||
:c:func:`!PyEval_ReleaseLock` have been officially deprecated. The
|
||||
thread-state aware APIs (such as :c:func:`PyEval_SaveThread`
|
||||
and :c:func:`PyEval_RestoreThread`) should be used instead.
|
||||
|
||||
* Due to security risks, :func:`asyncore.handle_accept` has been deprecated, and
|
||||
a new function, :func:`asyncore.handle_accepted`, was added to replace it.
|
||||
|
||||
(Contributed by Giampaolo Rodola in :issue:`6706`.)
|
||||
|
||||
* Due to the new :term:`GIL` implementation, :c:func:`PyEval_InitThreads()`
|
||||
cannot be called before :c:func:`Py_Initialize()` anymore.
|
||||
* Due to the new :term:`GIL` implementation, :c:func:`!PyEval_InitThreads`
|
||||
cannot be called before :c:func:`Py_Initialize` anymore.
|
||||
|
|
|
|||
|
|
@ -2304,7 +2304,7 @@ Functions and macros manipulating Py_UNICODE* strings:
|
|||
|
||||
Encoders:
|
||||
|
||||
* :c:func:`!PyUnicode_Encode`: use :c:func:`PyUnicode_AsEncodedObject`
|
||||
* :c:func:`!PyUnicode_Encode`: use :c:func:`!PyUnicode_AsEncodedObject`
|
||||
* :c:func:`!PyUnicode_EncodeUTF7`
|
||||
* :c:func:`!PyUnicode_EncodeUTF8`: use :c:func:`PyUnicode_AsUTF8` or
|
||||
:c:func:`PyUnicode_AsUTF8String`
|
||||
|
|
@ -2462,7 +2462,7 @@ Porting C code
|
|||
--------------
|
||||
|
||||
* In the course of changes to the buffer API the undocumented
|
||||
:c:member:`~Py_buffer.smalltable` member of the
|
||||
:c:member:`!smalltable` member of the
|
||||
:c:type:`Py_buffer` structure has been removed and the
|
||||
layout of the :c:type:`PyMemoryViewObject` has changed.
|
||||
|
||||
|
|
|
|||
|
|
@ -2512,7 +2512,7 @@ Changes in the Python API
|
|||
Changes in the C API
|
||||
--------------------
|
||||
|
||||
* The undocumented :c:member:`~PyMemoryViewObject.format` member of the
|
||||
* The undocumented :c:member:`!format` member of the
|
||||
(non-public) :c:type:`PyMemoryViewObject` structure has been removed.
|
||||
All extensions relying on the relevant parts in ``memoryobject.h``
|
||||
must be rebuilt.
|
||||
|
|
@ -2520,7 +2520,7 @@ Changes in the C API
|
|||
* The :c:type:`PyMemAllocator` structure was renamed to
|
||||
:c:type:`PyMemAllocatorEx` and a new ``calloc`` field was added.
|
||||
|
||||
* Removed non-documented macro :c:macro:`PyObject_REPR` which leaked references.
|
||||
* Removed non-documented macro :c:macro:`!PyObject_REPR()` which leaked references.
|
||||
Use format character ``%R`` in :c:func:`PyUnicode_FromFormat`-like functions
|
||||
to format the :func:`repr` of the object.
|
||||
(Contributed by Serhiy Storchaka in :issue:`22453`.)
|
||||
|
|
|
|||
|
|
@ -1574,12 +1574,12 @@ Build and C API Changes
|
|||
* :c:func:`Py_INCREF`, :c:func:`Py_DECREF`
|
||||
* :c:func:`Py_XINCREF`, :c:func:`Py_XDECREF`
|
||||
* :c:func:`PyObject_INIT`, :c:func:`PyObject_INIT_VAR`
|
||||
* Private functions: :c:func:`_PyObject_GC_TRACK`,
|
||||
:c:func:`_PyObject_GC_UNTRACK`, :c:func:`_Py_Dealloc`
|
||||
* Private functions: :c:func:`!_PyObject_GC_TRACK`,
|
||||
:c:func:`!_PyObject_GC_UNTRACK`, :c:func:`!_Py_Dealloc`
|
||||
|
||||
(Contributed by Victor Stinner in :issue:`35059`.)
|
||||
|
||||
* The :c:func:`PyByteArray_Init` and :c:func:`PyByteArray_Fini` functions have
|
||||
* The :c:func:`!PyByteArray_Init` and :c:func:`!PyByteArray_Fini` functions have
|
||||
been removed. They did nothing since Python 2.7.4 and Python 3.2.0, were
|
||||
excluded from the limited API (stable ABI), and were not documented.
|
||||
(Contributed by Victor Stinner in :issue:`35713`.)
|
||||
|
|
@ -1628,7 +1628,7 @@ Build and C API Changes
|
|||
parameter for indicating the number of positional-only arguments.
|
||||
(Contributed by Pablo Galindo in :issue:`37221`.)
|
||||
|
||||
* :c:func:`Py_SetPath` now sets :data:`sys.executable` to the program full
|
||||
* :c:func:`!Py_SetPath` now sets :data:`sys.executable` to the program full
|
||||
path (:c:func:`Py_GetProgramFullPath`) rather than to the program name
|
||||
(:c:func:`Py_GetProgramName`).
|
||||
(Contributed by Victor Stinner in :issue:`38234`.)
|
||||
|
|
@ -1845,11 +1845,11 @@ Changes in Python behavior
|
|||
always use ``sys.platform.startswith('aix')``.
|
||||
(Contributed by M. Felt in :issue:`36588`.)
|
||||
|
||||
* :c:func:`PyEval_AcquireLock` and :c:func:`PyEval_AcquireThread` now
|
||||
* :c:func:`!PyEval_AcquireLock` and :c:func:`!PyEval_AcquireThread` now
|
||||
terminate the current thread if called while the interpreter is
|
||||
finalizing, making them consistent with :c:func:`PyEval_RestoreThread`,
|
||||
:c:func:`Py_END_ALLOW_THREADS`, and :c:func:`PyGILState_Ensure`. If this
|
||||
behavior is not desired, guard the call by checking :c:func:`_Py_IsFinalizing`
|
||||
behavior is not desired, guard the call by checking :c:func:`!_Py_IsFinalizing`
|
||||
or :func:`sys.is_finalizing`.
|
||||
(Contributed by Joannah Nanjekye in :issue:`36475`.)
|
||||
|
||||
|
|
@ -2021,7 +2021,7 @@ Changes in the C API
|
|||
*cf_flags*.
|
||||
(Contributed by Guido van Rossum in :issue:`35766`.)
|
||||
|
||||
* The :c:func:`PyEval_ReInitThreads` function has been removed from the C API.
|
||||
* The :c:func:`!PyEval_ReInitThreads` function has been removed from the C API.
|
||||
It should not be called explicitly: use :c:func:`PyOS_AfterFork_Child`
|
||||
instead.
|
||||
(Contributed by Victor Stinner in :issue:`36728`.)
|
||||
|
|
@ -2121,7 +2121,7 @@ Changes in the C API
|
|||
|
||||
(Contributed by Antoine Pitrou in :issue:`32388`.)
|
||||
|
||||
* The functions :c:func:`PyNode_AddChild` and :c:func:`PyParser_AddToken` now accept
|
||||
* The functions :c:func:`!PyNode_AddChild` and :c:func:`!PyParser_AddToken` now accept
|
||||
two additional ``int`` arguments *end_lineno* and *end_col_offset*.
|
||||
|
||||
* The :file:`libpython38.a` file to allow MinGW tools to link directly against
|
||||
|
|
|
|||
|
|
@ -870,9 +870,9 @@ Deprecated
|
|||
users can leverage the Abstract Syntax Tree (AST) generation and compilation
|
||||
stage, using the :mod:`ast` module.
|
||||
|
||||
* The Public C API functions :c:func:`PyParser_SimpleParseStringFlags`,
|
||||
:c:func:`PyParser_SimpleParseStringFlagsFilename`,
|
||||
:c:func:`PyParser_SimpleParseFileFlags` and :c:func:`PyNode_Compile`
|
||||
* The Public C API functions :c:func:`!PyParser_SimpleParseStringFlags`,
|
||||
:c:func:`!PyParser_SimpleParseStringFlagsFilename`,
|
||||
:c:func:`!PyParser_SimpleParseFileFlags` and :c:func:`!PyNode_Compile`
|
||||
are deprecated and will be removed in Python 3.10 together with the old parser.
|
||||
|
||||
* Using :data:`NotImplemented` in a boolean context has been deprecated,
|
||||
|
|
@ -923,10 +923,10 @@ Deprecated
|
|||
(Contributed by Batuhan Taskaya in :issue:`39639` and :issue:`39969`
|
||||
and Serhiy Storchaka in :issue:`39988`.)
|
||||
|
||||
* The :c:func:`PyEval_InitThreads` and :c:func:`PyEval_ThreadsInitialized`
|
||||
* The :c:func:`!PyEval_InitThreads` and :c:func:`!PyEval_ThreadsInitialized`
|
||||
functions are now deprecated and will be removed in Python 3.11. Calling
|
||||
:c:func:`PyEval_InitThreads` now does nothing. The :term:`GIL` is initialized
|
||||
by :c:func:`Py_Initialize()` since Python 3.7.
|
||||
:c:func:`!PyEval_InitThreads` now does nothing. The :term:`GIL` is initialized
|
||||
by :c:func:`Py_Initialize` since Python 3.7.
|
||||
(Contributed by Victor Stinner in :issue:`39877`.)
|
||||
|
||||
* Passing ``None`` as the first argument to the :func:`shlex.split` function
|
||||
|
|
|
|||
|
|
@ -5036,15 +5036,15 @@ Limited API.
|
|||
|
||||
Deprecate the following functions to configure the Python initialization:
|
||||
|
||||
* :c:func:`PySys_AddWarnOptionUnicode`
|
||||
* :c:func:`PySys_AddWarnOption`
|
||||
* :c:func:`PySys_AddXOption`
|
||||
* :c:func:`PySys_HasWarnOptions`
|
||||
* :c:func:`Py_SetPath`
|
||||
* :c:func:`Py_SetProgramName`
|
||||
* :c:func:`Py_SetPythonHome`
|
||||
* :c:func:`Py_SetStandardStreamEncoding`
|
||||
* :c:func:`_Py_SetProgramFullPath`
|
||||
* :c:func:`!PySys_AddWarnOptionUnicode`
|
||||
* :c:func:`!PySys_AddWarnOption`
|
||||
* :c:func:`!PySys_AddXOption`
|
||||
* :c:func:`!PySys_HasWarnOptions`
|
||||
* :c:func:`!Py_SetPath`
|
||||
* :c:func:`!Py_SetProgramName`
|
||||
* :c:func:`!Py_SetPythonHome`
|
||||
* :c:func:`!Py_SetStandardStreamEncoding`
|
||||
* :c:func:`!_Py_SetProgramFullPath`
|
||||
|
||||
Use the new :c:type:`PyConfig` API of the :ref:`Python Initialization
|
||||
Configuration <init-config>` instead (:pep:`587`).
|
||||
|
|
|
|||
|
|
@ -8765,7 +8765,7 @@ for relative path to files in current directory.
|
|||
.. nonce: fmehdG
|
||||
.. section: C API
|
||||
|
||||
The :c:func:`PyByteArray_Init` and :c:func:`PyByteArray_Fini` functions have
|
||||
The :c:func:`!PyByteArray_Init` and :c:func:`!PyByteArray_Fini` functions have
|
||||
been removed. They did nothing since Python 2.7.4 and Python 3.2.0, were
|
||||
excluded from the limited API (stable ABI), and were not documented.
|
||||
|
||||
|
|
@ -8836,7 +8836,7 @@ Py_LIMITED_API. Patch by Arthur Neufeld.
|
|||
.. nonce: gFd85N
|
||||
.. section: C API
|
||||
|
||||
The :c:func:`_PyObject_GC_TRACK` and :c:func:`_PyObject_GC_UNTRACK` macros
|
||||
The :c:func:`!_PyObject_GC_TRACK` and :c:func:`!_PyObject_GC_UNTRACK` macros
|
||||
have been removed from the public C API.
|
||||
|
||||
..
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ Galindo.
|
|||
.. nonce: CjRps3
|
||||
.. section: Core and Builtins
|
||||
|
||||
:c:func:`PyEval_AcquireLock` and :c:func:`PyEval_AcquireThread` now
|
||||
:c:func:`!PyEval_AcquireLock` and :c:func:`!PyEval_AcquireThread` now
|
||||
terminate the current thread if called while the interpreter is finalizing,
|
||||
making them consistent with :c:func:`PyEval_RestoreThread`,
|
||||
:c:func:`Py_END_ALLOW_THREADS`, and :c:func:`PyGILState_Ensure`.
|
||||
|
|
|
|||
|
|
@ -2047,6 +2047,6 @@ unbound methods. These are objects supporting the optimization given by the
|
|||
.. nonce: FR-dMP
|
||||
.. section: C API
|
||||
|
||||
The :c:func:`PyEval_ReInitThreads` function has been removed from the C API.
|
||||
The :c:func:`!PyEval_ReInitThreads` function has been removed from the C API.
|
||||
It should not be called explicitly: use :c:func:`PyOS_AfterFork_Child`
|
||||
instead.
|
||||
|
|
|
|||
|
|
@ -5535,7 +5535,7 @@ Tyler Kieft.
|
|||
.. nonce: d0bhEA
|
||||
.. section: C API
|
||||
|
||||
:c:func:`Py_SetPath` now sets :data:`sys.executable` to the program full
|
||||
:c:func:`!Py_SetPath` now sets :data:`sys.executable` to the program full
|
||||
path (:c:func:`Py_GetProgramFullPath`) rather than to the program name
|
||||
(:c:func:`Py_GetProgramName`).
|
||||
|
||||
|
|
@ -5546,8 +5546,8 @@ path (:c:func:`Py_GetProgramFullPath`) rather than to the program name
|
|||
.. nonce: ZbquVK
|
||||
.. section: C API
|
||||
|
||||
Python ignored arguments passed to :c:func:`Py_SetPath`,
|
||||
:c:func:`Py_SetPythonHome` and :c:func:`Py_SetProgramName`: fix Python
|
||||
Python ignored arguments passed to :c:func:`!Py_SetPath`,
|
||||
:c:func:`!Py_SetPythonHome` and :c:func:`!Py_SetProgramName`: fix Python
|
||||
initialization to use specified arguments.
|
||||
|
||||
..
|
||||
|
|
|
|||
|
|
@ -1234,8 +1234,8 @@ method name in the SystemError "bad call flags" error message to ease debug.
|
|||
.. nonce: GOYtIm
|
||||
.. section: C API
|
||||
|
||||
Deprecated :c:func:`PyEval_InitThreads` and
|
||||
:c:func:`PyEval_ThreadsInitialized`. Calling :c:func:`PyEval_InitThreads`
|
||||
Deprecated :c:func:`!PyEval_InitThreads` and
|
||||
:c:func:`!PyEval_ThreadsInitialized`. Calling :c:func:`!PyEval_InitThreads`
|
||||
now does nothing.
|
||||
|
||||
..
|
||||
|
|
|
|||
Loading…
Reference in a new issue