PEP 620: typos

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 makes possible to experiment in CPython more advanced optimizations
-than just micro-optimizations, like tagged pointers.
+It becomes possible to experiment in CPython with more advanced
+optimizations 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 introduce incompatible
-changes to the C API`_ didactes the rhythm.
+changes are already completed. The `Process to reduce the number of
+broken C extensions`_ didactes the rhythm.
 
 
 Motivation
@@ -39,9 +39,9 @@ compatibility issues.
 Adding a new member breaks the stable ABI (PEP 384), especially for
 types declared statically (e.g. ``static PyTypeObject MyType =
 {...};``). In Python 3.4, the PEP 442 "Safe object finalization" added
-``tp_finalize`` member at the end of the ``PyTypeObject`` structure. For
-ABI backward compatibility, a new ``Py_TPFLAGS_HAVE_FINALIZE`` type flag
-was required to announce if the type structure contains the
+the ``tp_finalize`` member at the end of the ``PyTypeObject`` structure.
+For ABI backward compatibility, a new ``Py_TPFLAGS_HAVE_FINALIZE`` type
+flag was required to announce if the type structure contains the
 ``tp_finalize`` member. The flag was removed in Python 3.8 (`bpo-32388
 <https://bugs.python.org/issue32388>`_).
 
@@ -50,7 +50,7 @@ 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
 3.8 final release. Finally, the member was removed again in Python 3.9.
 
-C extensions rely on the ability to access directly structures members,
+C extensions rely on the ability to access directly structure members,
 indirectly through the C API, or even directly. Modifying structures
 like ``PyListObject`` cannot be even considered.
 
@@ -106,7 +106,7 @@ Why is PyPy more efficient than CPython?
 ----------------------------------------
 
 The PyPy project is a Python implementation which is 4.2x faster than
-CPython in average. PyPy developers chose to not fork CPython, but start
+CPython on average. PyPy developers chose to not fork CPython, but start
 from scratch to have more freedom in terms of optimization choices.
 
 PyPy does not use reference counting, but a tracing garbage collector
@@ -129,7 +129,7 @@ Since the C API requires ``PyObject*`` and allows to access directly
 structure members, PyPy has to associate a CPython object to PyPy
 objects and maintain both consistent. Converting a PyPy object to a
 CPython object is inefficient. Moreover, reference counting also has to
-be implemented on top on PyPy tracing garbage collector.
+be implemented on top of PyPy tracing garbage collector.
 
 These conversions are required because the Python C API is too close to
 the CPython implementation: there is no high-level abstraction.
@@ -150,7 +150,7 @@ Hide implementation details
 
 Hiding implementation details from the C API has multiple advantages:
 
-* It becomes possible to experiment in CPython more advanced
+* 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.
@@ -167,7 +167,7 @@ Relationship with the limited C API
 
 The PEP 384 "Defining a Stable ABI" is in Python 3.4. It introduces the
 "limited C API": a subset of the C API. When the limited C API is used,
-it becomes possible to build a C extensions only once and uses it on
+it becomes possible to build a C extension only once and use it on
 multiple Python versions: that's the stable ABI.
 
 The main limitation of the PEP 384 is that C extensions have to opt-in
@@ -246,7 +246,7 @@ completed in Python 3.8:
 Move private functions to the internal C API
 --------------------------------------------
 
-Private functions which exposes implementation details must be moved to
+Private functions which expose implementation details must be moved to
 the internal C API.
 
 If a C extension relies on a CPython private function which exposes
@@ -361,7 +361,7 @@ is exposed in the C API. All structures must become opaque, since they
         double ob_fval;
     } PyFloatObject;
 
-Making ``PyObject`` fully opaque requires to convert ``Py_INCREF()`` and
+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
 structures opaque.
@@ -369,12 +369,12 @@ structures opaque.
 Making ``PyTypeObject`` structure opaque breaks C extensions declaring
 types statically (e.g. ``static PyTypeObject MyType = {...};``). C
 extensions must use ``PyType_FromSpec()`` to allocate types on the heap
-instead. Using heap types have other advantages like being compatible
+instead. Using heap types has other advantages like being compatible
 with subinterpreters. Combined with PEP 489 "Multi-phase extension
 module initialization", it makes a C extension behavior closer to a
 Python module, like allowing to create more than one module instance.
 
-Making ``PyThreadState`` structure opaque requires to add getter and
+Making ``PyThreadState`` structure opaque requires adding getter and
 setter functions for members used by C extensions.
 
 **STATUS**: In Progress (started in Python 3.8)
@@ -407,7 +407,7 @@ The ``Py_TYPE()`` function gets an object type, its ``PyObject.ob_type``
 member. It is implemented as a macro which can be used as an l-value to
 set the type: ``Py_TYPE(obj) = new_type``. This code relies on the
 assumption that ``PyObject.ob_type`` can be modified directly. It
-prevents to make the ``PyObject`` structure opaque.
+prevents making the ``PyObject`` structure opaque.
 
 New setter functions ``Py_SET_TYPE()``, ``Py_SET_REFCNT()`` and
 ``Py_SET_SIZE()`` are added and must be used instead.
@@ -486,7 +486,7 @@ converted to static inline functions to disallow that.
 New pythoncapi_compat.h header file
 -----------------------------------
 
-Making structures opaque require to require to modify C extensions to
+Making structures opaque requires modifying C extensions to
 use getter and setter functions. The practical issue is how to keep
 support for old Python versions which don't have these functions.
 
@@ -518,16 +518,19 @@ provides new C API functions to old Python versions. Example::
 Using this header file, ``Py_SET_TYPE()`` can be used on old Python
 versions as well.
 
-Developers can to copy this file in their project, or even to only
+Developers can copy this file in their project, or even to only
 copy/paste the few functions needed by their C extension.
 
-**STATUS**: In Progress (implemented but not shiped by CPython yet)
+**STATUS**: In Progress (implemented but not distributed by CPython yet)
 
 The ``pythoncapi_compat.h`` header file is currently developer at:
 https://github.com/pythoncapi/pythoncapi_compat
 
-Process to introduce incompatible changes to the C API
-======================================================
+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:
 
 * Estimate how many popular C extensions are affected by the
   incompatible change.
@@ -550,9 +553,9 @@ fixes for every broken project.
 
 Since more and more C extensions are written using Cython, rather
 directly using the C API, it is important to ensure that Cython is
-prepared is advance for incompatible changes. It gives more time for C
+prepared in advance for incompatible changes. It gives more time for C
 extension maintainers to release a new version with code generated with
-the updated Cython (for C extensions shipping the code generated by
+the updated Cython (for C extensions distributing the code generated by
 Cython).
 
 Future incompatible changes can be announced by deprecating a function
@@ -561,10 +564,10 @@ in the documentation and by annotating the function with
 usage of a macro as l-value cannot be deprecated with
 ``Py_DEPRECATED()``.
 
-The important part is coordination and balance the tradeoff between
-CPython evolutions and backward compatibility. For example, breaking a
-random, old, obscure and unmaintained C extension on PyPI is less severe
-than breaking numpy.
+The important part is coordination and finding a balance between CPython
+evolutions and backward compatibility. For example, breaking a random,
+old, obscure and unmaintained C extension on PyPI is less severe than
+breaking numpy.
 
 If a change is reverted, we move back to the coordination step to better
 prepare the change. Once more C extensions are ready, the incompatible
@@ -574,9 +577,10 @@ change can be reconsidered.
 Version History
 ===============
 
-* Version 3, June 2020: PEP rewritten from scratch. Python now ships
-  a new ``pythoncapi_compat.h`` header and a process is defined
-  to introduced incompatible C API changes.
+* 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
+  API incompatible changes listed in this PEP.
 * Version 2, April 2020:
   `PEP: Modify the C API to hide implementation details
   <https://mail.python.org/archives/list/python-dev@python.org/thread/HKM774XKU7DPJNLUTYHUB5U6VR6EQMJF/#TKHNENOXP6H34E73XGFOL2KKXSM4Z6T2>`_.