MAL's review

peps/pep-0733.rst

@@ -55,20 +55,23 @@ criteria.
 Introduction
 ============
 
-Python's C API was not designed for the purposes it currently fulfills.
-It evolved from what was initially the internal API between the C code
-of the interpreter and the Python language and libraries. In its first
-incarnation, it was exposed to make it possible to embed Python into C/C++
-applications and to write extension modules in C/C++.
+Python's C API was not designed for the different purposes it currently
+fulfills.  It evolved from what was initially the internal API between
+the C code of the interpreter and the Python language and libraries.
+In its first incarnation, it was exposed to make it possible to embed
+Python into C/C++ applications and to write extension modules in C/C++.
 These capabilities were instrumental to the growth of Python's ecosystem.
 Over the decades, the C API grew to provide different tiers of stability,
 conventions changed, and new usage patterns have emerged, such as bindings
-to languages other than C/C++. In addition, CPython is no longer the only
-implementation of the C API, and some of the design decisions made when
-it was, are difficult for alternative implementations to work with
+to languages other than C/C++. However, this growth was not supported by
+clearly documented guidelines, resulting in inconsitent approaches to
+API design in different subsystems of CPython. In addition, CPython is
+no longer the only implementation of Python, and some of the design
+decisions made when it was, are difficult for alternative implementations
+to work with
 [`Issue 64 <https://github.com/capi-workgroup/problems/issues/64>`__].
-Finally, lessons were learned and mistakes in both the design and the
-implementation of the C API were identified.
+In the meantime, lessons were learned and mistakes in both the design
+and the implementation of the C API were identified.
 
 Evolving the C API is hard due to the combination of backwards
 compatibility constraints and its inherent complexity, both
@@ -81,8 +84,9 @@ or replacement of the C API, each representing a deep analysis of
 the problems.  At the 2023 Language Summit, three back-to-back
 sessions were devoted to different aspects of the C API. There is
 general agreement that a new design can remedy the problems that
-the C API has accumulated over the last 30 years, while at the same
-time updating it for use cases that it was not originally designed for.
+the C API has accumulated over the last 30 years, while at the
+same time updating it for use cases that it was not originally
+designed for.
 
 However, there was also a sense at the Language Summit that we are
 trying to discuss solutions without a clear common understanding
@@ -138,7 +142,11 @@ Extension Writers
 -----------------
 
 Extension writers are the traditional users of the C API. Their requirements
-are the common actions listed above.
+are the common actions listed above. They also commonly need to:
+
+* Create new modules
+* Efficiently interface between modules at the C level
+
 
 Authors of Embedded Python Applications
 ---------------------------------------
@@ -149,7 +157,8 @@ Applications with an embedded Python interpreter. Examples are
 
 They need to be able to:
 
-* Configure the interpreter (import paths, inittab, ``sys.argv``, etc.).
+* Configure the interpreter (import paths, inittab, ``sys.argv``, memory
+  allocator, etc.).
 * Interact with the execution model and program lifetime, including
   clean interpreter shutdown and restart.
 * Represent complex data models in a way Python can use without