PEP 620: typos

This commit is contained in:
Victor Stinner 2020-06-22 13:06:55 +02:00
parent b343c331d9
commit bdf57430df
1 changed files with 13 additions and 13 deletions

View File

@ -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