address some of the review comments

peps/pep-0733.rst

@@ -158,8 +158,7 @@ There are several projects that implement alternatives to the
 C API, which offer extension users advantanges over programming
 directly with the C API. These APIs are implemented with the
 C API, and in some cases by using CPython internals.
-Some examples are
-`Cython <https://cython.org>`__,
+Examples are
 `HPy <https://hpyproject.org>`__ and
 `pythoncapi-compat <https://pythoncapi-compat.readthedocs.io/en/latest/>`__.
 CPython's DSL for parsing function arguments, the
@@ -170,19 +169,20 @@ Such systems need minimal building blocks for accessing CPython
 efficiently. They don't necessarily need an ergonomic API, because
 they typically generate code that is not intended to be read
 by humans. But they do need it to be comprehensive enough so that
-they don't need to access internals, while offering them stability,
-and without sacrificing performance.
+they don't need to access internals, without sacrificing performance.
+
+These tools might also benefit from a choice between a more stable
+and a more performant (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.
 
-An alternative is to have a fast API tier with less error checking
-and lower stability guarantees. Then the developers and users of
-these tools can choose whether to generate code that uses the
-faster or the safer and more stable version of the API.
 
 Binding Generators
 ------------------
 
 Libraries that create bindings between Python and other object models,
 paradigms or languages, such as
+`Cython <https://cython.org>`__,
 `pybind11 <https://pybind11.readthedocs.io/en/stable/>`__ for C++11,
 `PyO3 <https://github.com/PyO3/pyo3>`__ for Rust,
 `PySide <https://pypi.org/project/PySide/>`__ for Qt,
@@ -563,7 +563,7 @@ are not included from ``Python.h``.
 
 **Naming**
 
-``PyLong`` and ``PyUnicode`` use names which don't match the Python
+``PyLong`` and ``PyUnicode`` use names which no longer match the Python
 types they represent (``int``/``str``). This can be fixed in a new API
 [`Issue 14 <https://github.com/capi-workgroup/problems/issues/14>`__].
 
@@ -591,8 +591,7 @@ There aren't currently reliable introspection capabilities for objects
 defined in C in the same way as there are for Python objects
 [`Issue 32 <https://github.com/capi-workgroup/problems/issues/32>`__].
 
-Efficient type checking for heap types, similar to what ``Py*_Check``
-can do for a static type
+Efficient type checking for heap types
 [`Issue 17 <https://github.com/capi-workgroup/problems/issues/17>`__].
 
 Improved Interaction with Other Languages