Address review comments from Jelle and David

peps/pep-0733.rst

@@ -191,6 +191,10 @@ paradigms or languages, such as
 `PyJNIus <https://github.com/kivy/pyjnius/>`__ for Java, or
 `SWIG <https://swig.org/>`__ for C/C++.
 
+Some of the alternative APIs mentioned in the previous section create
+alternative object models and therefore they can also be seen as
+belonging to this category.
+
 They need to:
 
 * Create custom objects (e.g. function/module objects
@@ -540,16 +544,6 @@ The meaning of ``Py_SIZE`` depends on the type and is not always
 reliable
 [`Issue 10 <https://github.com/capi-workgroup/problems/issues/10>`__].
 
-**Naming**
-
-``PyLong`` and ``PyUnicode`` use names which don't 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>`__].
-
-There are identifiers in the API which are lacking a ``Py``/``_Py``
-prefix
-[`Issue 46 <https://github.com/capi-workgroup/problems/issues/46>`__].
-
 Some API function do not have the same behaviour as their Python
 equivalents.  The behaviour of ``PyIter_Next`` is different from
 ``tp_iternext``.
@@ -565,6 +559,15 @@ The fact that ``PyArg_ParseTupleAndKeywords`` takes a non-const
 are not included from ``Python.h``.
 [`Issue 43 <https://github.com/capi-workgroup/problems/issues/43>`__].
 
+**Naming**
+
+``PyLong`` and ``PyUnicode`` use names which don't 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>`__].
+
+There are identifiers in the API which are lacking a ``Py``/``_Py``
+prefix
+[`Issue 46 <https://github.com/capi-workgroup/problems/issues/46>`__].
 
 Missing Functionality
 ---------------------