PEP 620: typos
This commit is contained in:
parent
b343c331d9
commit
bdf57430df
26
pep-0620.rst
26
pep-0620.rst
|
@ -16,15 +16,15 @@ Once most implementation details will be hidden, evolution of CPython
|
|||
internals would be less limited by C API backward compatibility issues.
|
||||
It will be way easier to add new features.
|
||||
|
||||
It becomes possible to experiment in CPython with more advanced
|
||||
optimizations than just micro-optimizations, like tagged pointers.
|
||||
It becomes possible to experiment with more advanced optimizations in
|
||||
CPython than just micro-optimizations, like tagged pointers.
|
||||
|
||||
Define a process to reduce the number of broken C extensions.
|
||||
|
||||
The implementation of this PEP is expected to be done carefully over
|
||||
multiple Python versions. It already started in Python 3.7 and most
|
||||
changes are already completed. The `Process to reduce the number of
|
||||
broken C extensions`_ didactes the rhythm.
|
||||
broken C extensions`_ dictates the rhythm.
|
||||
|
||||
|
||||
Motivation
|
||||
|
@ -150,10 +150,10 @@ Hide implementation details
|
|||
|
||||
Hiding implementation details from the C API has multiple advantages:
|
||||
|
||||
* It becomes possible to experiment in CPython more with advanced
|
||||
optimizations than just micro-optimizations. For example, tagged
|
||||
pointers, and replace the garbage collector with a tracing garbage
|
||||
collector which can move objects.
|
||||
* It becomes possible to experiment with more advanced optimizations in
|
||||
CPython than just micro-optimizations. For example, tagged pointers,
|
||||
and replace the garbage collector with a tracing garbage collector
|
||||
which can move objects.
|
||||
* Adding new features in CPython becomes easier.
|
||||
* PyPy should be able to avoid conversions to CPython objects in more
|
||||
cases: keep efficient PyPy objects.
|
||||
|
@ -363,7 +363,7 @@ is exposed in the C API. All structures must become opaque, since they
|
|||
|
||||
Making ``PyObject`` fully opaque requires converting ``Py_INCREF()`` and
|
||||
``Py_DECREF()`` macros to function calls. This change has an impact on
|
||||
performance. It is likely to be one of the very last change when making
|
||||
performance. It is likely to be one of the very last changes when making
|
||||
structures opaque.
|
||||
|
||||
Making ``PyTypeObject`` structure opaque breaks C extensions declaring
|
||||
|
@ -529,8 +529,8 @@ https://github.com/pythoncapi/pythoncapi_compat
|
|||
Process to reduce the number of broken C extensions
|
||||
===================================================
|
||||
|
||||
Process to reduce the number of broken C extensions when introduce C API
|
||||
incompatible changes listed in this PEP:
|
||||
Process to reduce the number of broken C extensions when introducing C
|
||||
API incompatible changes listed in this PEP:
|
||||
|
||||
* Estimate how many popular C extensions are affected by the
|
||||
incompatible change.
|
||||
|
@ -545,10 +545,10 @@ incompatible changes listed in this PEP:
|
|||
C extensions maintainers to prepare their project for the next Python.
|
||||
* If the change breaks too many projects, reverting the change should be
|
||||
discussed, taking in account the number of broken packages, their
|
||||
importance in the Python commmunity, and the importance of the change.
|
||||
importance in the Python community, and the importance of the change.
|
||||
|
||||
The coordination usually means reporting issues to the projects, or even
|
||||
propose changes. It does not require waiting for a new release including
|
||||
proposing changes. It does not require waiting for a new release including
|
||||
fixes for every broken project.
|
||||
|
||||
Since more and more C extensions are written using Cython, rather
|
||||
|
@ -579,7 +579,7 @@ Version History
|
|||
|
||||
* Version 3, June 2020: PEP rewritten from scratch. Python now
|
||||
distributes a new ``pythoncapi_compat.h`` header and a process is
|
||||
defined to reduce the number of broken C extensions when introduce C
|
||||
defined to reduce the number of broken C extensions when introducing C
|
||||
API incompatible changes listed in this PEP.
|
||||
* Version 2, April 2020:
|
||||
`PEP: Modify the C API to hide implementation details
|
||||
|
|
Loading…
Reference in New Issue