reviews from Greg and Mark

peps/pep-0733.rst

@@ -130,7 +130,6 @@ all types of API users:
 * Introspect objects, including types, instances, and functions
 * Raise and handle exceptions
 * Import modules
-* Manage sub-interpreters
 * Access to Python's OS interface
 
 The following sections look at the unique requirements of various stakeholders.
@@ -156,8 +155,8 @@ They need to be able to:
 * Represent complex data models in a way Python can use without
   having to create deep copies.
 * Provide and import frozen modules.
-* Run multiple independent interpreters (in particular, when embedded
-  in a library that wants to avoid global effects).
+* Run and manage multiple independent interpreters (in particular, when
+  embedded in a library that wants to avoid global effects).
 
 Python Implementations
 ----------------------
@@ -229,12 +228,13 @@ Binding generators often need to:
 * Dynamically adapt foreign objects (strings, GC'd containers), with
   low overhead.
 * Adapt external mechanisms, execution models and guarantees to the
-  Python way (green threads/continuations, one-writer-or-multiple-readers
-  semantics, virtual multiple inheritance, 1-based indexing, super-long
-  inheritance chains, goroutines, channels, etc.).
+  Python way (stackful coroutines, continuations,
+  one-writer-or-multiple-readers semantics, virtual multiple inheritance,
+  1-based indexing, super-long inheritance chains, goroutines, channels,
+  etc.).
 
 These tools might also benefit from a choice between a more stable
-and a more performant (possibly lower-level) API. Their users could
+and a faster (possibly lower-level) API. Their users could
 then decide whether they can afford to regenerate the code often or
 trade some performance for more stability and less maintenance work.
 
@@ -262,8 +262,8 @@ API functions that take a C string literal for lookups based
 on a Python string are very convenient
 [`Issue 30 <https://github.com/capi-workgroup/problems/issues/30#issuecomment-1550098113>`__].
 
-The Limited API and stable ABI hide implementation details and
-make it easier to evolve Python
+The limited API demonstrates that an API which hides implementation
+details makes it easier to evolve Python
 [`Issue 30 <https://github.com/capi-workgroup/problems/issues/30#issuecomment-1560083258>`__].
 
 C API problems
@@ -367,16 +367,16 @@ Object Reference Management
 ---------------------------
 
 There are C API functions that return borrowed references, and
-functions that steal references to arguments, but there isn't a
+functions that decref arguments, but there isn't a
 naming convention that makes this obvious, so this is error prone
 [`Issue 8 <https://github.com/capi-workgroup/problems/issues/8>`__
 and `Issue 52 <https://github.com/capi-workgroup/problems/issues/52>`__].
 The terminology used to describe these situations in the documentation
 can also be improved
 [`Issue 11 <https://github.com/capi-workgroup/problems/issues/11>`__].
 
-A more radical change is necessary in the case of functions that
-return borrowed references (such as ``PyList_GetItem``)
+A more radical change is necessary in the case of a function that
+returns a ``PyObject*`` that it did not incref (such as ``PyList_GetItem``)
 [`Issue 5 <https://github.com/capi-workgroup/problems/issues/5>`__ and
 `Issue 21 <https://github.com/capi-workgroup/problems/issues/21>`__]
 or pointers to parts of the internal structure of an object
@@ -525,7 +525,8 @@ Use of the C Language
 
 A number of issues were raised with respect to the way that CPython
 uses the C language. First there is the issue of which C dialect
-we use, and how we test our compatibility with it
+we use, and how we test our compatibility with it, as well as API
+header compatibility with C++ dialects
 [`Issue 42 <https://github.com/capi-workgroup/problems/issues/42>`__].
 
 Usage of ``const`` in the API is currently sparse, but it is not