iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
pep-0620.rst
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. internals would be less limited by C API backward compatibility issues.
It will be way easier to add new features. It will be way easier to add new features.
It becomes possible to experiment in CPython with more advanced It becomes possible to experiment with more advanced optimizations in
optimizations than just micro-optimizations, like tagged pointers. CPython than just micro-optimizations, like tagged pointers.
Define a process to reduce the number of broken C extensions. Define a process to reduce the number of broken C extensions.
The implementation of this PEP is expected to be done carefully over The implementation of this PEP is expected to be done carefully over
multiple Python versions. It already started in Python 3.7 and most multiple Python versions. It already started in Python 3.7 and most
changes are already completed. The `Process to reduce the number of changes are already completed. The `Process to reduce the number of
broken C extensions`_ didactes the rhythm. broken C extensions`_ dictates the rhythm.
Motivation Motivation
@ -150,10 +150,10 @@ Hide implementation details
Hiding implementation details from the C API has multiple advantages: Hiding implementation details from the C API has multiple advantages:
* It becomes possible to experiment in CPython more with advanced * It becomes possible to experiment with more advanced optimizations in
optimizations than just micro-optimizations. For example, tagged CPython than just micro-optimizations. For example, tagged pointers,
pointers, and replace the garbage collector with a tracing garbage and replace the garbage collector with a tracing garbage collector
collector which can move objects. which can move objects.
* Adding new features in CPython becomes easier. * Adding new features in CPython becomes easier.
* PyPy should be able to avoid conversions to CPython objects in more * PyPy should be able to avoid conversions to CPython objects in more
cases: keep efficient PyPy objects. 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 Making ``PyObject`` fully opaque requires converting ``Py_INCREF()`` and
``Py_DECREF()`` macros to function calls. This change has an impact on ``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. structures opaque.
Making ``PyTypeObject`` structure opaque breaks C extensions declaring 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
=================================================== ===================================================
Process to reduce the number of broken C extensions when introduce C API Process to reduce the number of broken C extensions when introducing C
incompatible changes listed in this PEP: API incompatible changes listed in this PEP:
* Estimate how many popular C extensions are affected by the * Estimate how many popular C extensions are affected by the
incompatible change. incompatible change.
@ -545,10 +545,10 @@ incompatible changes listed in this PEP:
C extensions maintainers to prepare their project for the next Python. C extensions maintainers to prepare their project for the next Python.
* If the change breaks too many projects, reverting the change should be * If the change breaks too many projects, reverting the change should be
discussed, taking in account the number of broken packages, their 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 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. fixes for every broken project.
Since more and more C extensions are written using Cython, rather 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 * Version 3, June 2020: PEP rewritten from scratch. Python now
distributes a new ``pythoncapi_compat.h`` header and a process is 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. API incompatible changes listed in this PEP.
* Version 2, April 2020: * Version 2, April 2020:
`PEP: Modify the C API to hide implementation details `PEP: Modify the C API to hide implementation details