Update PEP 620 (#1450)
This commit is contained in:
parent
382f0dfc7d
commit
501ba2d69b
27
pep-0620.rst
27
pep-0620.rst
|
@ -50,19 +50,17 @@ released in 2009, has been removed in the Python 3.8 development cycle.
|
||||||
But the change broke too many C extensions and had to be reverted before
|
But the change broke too many C extensions and had to be reverted before
|
||||||
3.8 final release. Finally, the member was removed again in Python 3.9.
|
3.8 final release. Finally, the member was removed again in Python 3.9.
|
||||||
|
|
||||||
C extensions rely on the ability to access directly structure members,
|
C extensions rely on the ability to access structure members,
|
||||||
indirectly through the C API, or even directly. Modifying structures
|
indirectly through the C API, or even directly. Modifying structures
|
||||||
like ``PyListObject`` cannot be even considered.
|
like ``PyListObject`` cannot be even considered.
|
||||||
|
|
||||||
The ``PyTypeObject`` structure is the one which evolved the most, simply
|
The ``PyTypeObject`` structure is the one which evolved the most, simply
|
||||||
because there was no other way to evolve CPython than modifying it.
|
because there was no other way to evolve CPython than modifying it.
|
||||||
|
|
||||||
In the C API, all Python objects are passed as ``PyObject*``: a pointer
|
A C extension can technically dereference a ``PyObject*`` pointer and
|
||||||
to a ``PyObject`` structure. Experimenting tagged pointers in CPython is
|
access ``PyObject`` members. This prevents experiments like tagged
|
||||||
blocked by the fact that a C extension can technically dereference a
|
pointers (storing small values as ``PyObject*`` which does not point to
|
||||||
``PyObject*`` pointer and access ``PyObject`` members. Small "objects"
|
a valid ``PyObject`` structure).
|
||||||
can be stored as a tagged pointer with no concrete ``PyObject``
|
|
||||||
structure.
|
|
||||||
|
|
||||||
Replacing Python garbage collector with a tracing garbage collector
|
Replacing Python garbage collector with a tracing garbage collector
|
||||||
would also need to remove ``PyObject.ob_refcnt`` reference counter,
|
would also need to remove ``PyObject.ob_refcnt`` reference counter,
|
||||||
|
@ -345,9 +343,18 @@ Macros converted to regular functions in Python 3.9:
|
||||||
Make structures opaque
|
Make structures opaque
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
All structures of the C API should become opaque: C extensions must
|
The following structures of the C API become opaque:
|
||||||
use getter or setter functions to get or set structure members. For
|
|
||||||
example, ``tuple->ob_item[0]`` must be replaced with
|
* ``PyInterpreterState``
|
||||||
|
* ``PyThreadState``
|
||||||
|
* ``PyGC_Head``
|
||||||
|
* ``PyTypeObject``
|
||||||
|
* ``PyObject`` and ``PyVarObject``
|
||||||
|
* ``PyTypeObject``
|
||||||
|
* All types which inherit from ``PyObject`` or ``PyVarObject``
|
||||||
|
|
||||||
|
C extensions must use getter or setter functions to get or set structure
|
||||||
|
members. For example, ``tuple->ob_item[0]`` must be replaced with
|
||||||
``PyTuple_GET_ITEM(tuple, 0)``.
|
``PyTuple_GET_ITEM(tuple, 0)``.
|
||||||
|
|
||||||
To be able to move away from reference counting, ``PyObject`` must
|
To be able to move away from reference counting, ``PyObject`` must
|
||||||
|
|
Loading…
Reference in New Issue