Apply suggestions from code review

Co-authored-by: Terry Jan Reedy <[email protected]>
Co-authored-by: Steve Dower <[email protected]>

peps/pep-0733.rst

@@ -27,7 +27,7 @@ criteria.
 Introduction
 ============
 
-Python's C API was not designed for the purposes it currently fulfils.
+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++
@@ -405,8 +405,8 @@ in the dictionary
 [`Issue 51 <https://github.com/capi-workgroup/problems/issues/51>`__].
 
 Python code never executes with an in-flight exception (by definition),
-and by the same token C API functions should never be called with the error
-indicator set. This is currently not checked in most C API functions, and
+and typically code using native functions should also be interrupted by
+an error being raised. This is not checked in most C API functions, and
 there are places in the interpreter where error handling code calls a C API
 function while an exception is set. For example, see the call to
 ``PyUnicode_FromString`` in the error handler of ``_PyErr_WriteUnraisableMsg``
@@ -501,7 +501,7 @@ clear whether this is something that we should consider changing
 [`Issue 38 <https://github.com/capi-workgroup/problems/issues/38>`__].
 
 We currently use the C types ``long`` and ``int``, where fixed-width integers
-such as ``int32_t`` and ``int64_t`` would have been better choices
+such as ``int32_t`` and ``int64_t`` may now be better choices
 [`Issue 27 <https://github.com/capi-workgroup/problems/issues/27>`__].
 
 We are using C language features which are hard for other languages