PEP 554: minor corrections. (gh-768)

There were a few typos and minor updates. Mostly the PEP is still up-to-date.

pep-0554.rst

@@ -23,7 +23,7 @@ provides the basis for an
 This proposal introduces the stdlib ``interpreters`` module.  The module
 will be `provisional <Provisional Status_>`_.  It exposes the basic
 functionality of subinterpreters already provided by the C-API, along
-with new functionality for sharing data between interpreters.
+with new (basic) functionality for sharing data between interpreters.
 
 
 Proposal
@@ -52,7 +52,7 @@ At first only the following types will be supported for sharing:
 * int
 * PEP 3118 buffer objects (via ``send_buffer()``)
 
-Support for other basic types (e.g. int, Ellipsis) will be added later.
+Support for other basic types (e.g. bool, float, Ellipsis) will be added later.
 
 API summary for interpreters module
 -----------------------------------
@@ -65,7 +65,7 @@ For creating and using interpreters:
 
 +------------------------------+----------------------------------------------+
 | signature                    | description                                  |
-+============================+=+==============================================+
++==============================+==============================================+
 | list_all() -> [Intepreter]   | Get all existing interpreters.               |
 +------------------------------+----------------------------------------------+
 | get_current() -> Interpreter | Get the currently running interpreter.       |
@@ -82,7 +82,7 @@ For creating and using interpreters:
 +-----------------------+-----------------------------------------------------+
 | .id                   | The interpreter's ID (read-only).                   |
 +-----------------------+-----------------------------------------------------+
-| .is_running() -> Bool | Is the interpreter currently executing code?        |
+| .is_running() -> bool | Is the interpreter currently executing code?        |
 +-----------------------+-----------------------------------------------------+
 | .destroy()            | Finalize and destroy the interpreter.               |
 +-----------------------+-----------------------------------------------------+
@@ -239,8 +239,8 @@ Handling an exception
        interp.run(tw.dedent("""
            raise KeyError
            """))
-   except KeyError:
-       print("got the error from the subinterpreter")
+   except interpreters.RunFailedError as exc:
+       print(f"got the error from the subinterpreter: {exc}")
 
 Synchronize using a channel
 ---------------------------
@@ -600,9 +600,10 @@ Existing Usage
 
 Subinterpreters are not a widely used feature.  In fact, the only
 documented cases of wide-spread usage are
-`mod_wsgi <https://github.com/GrahamDumpleton/mod_wsgi>`_ and
-`JEP <https://github.com/ninia/jep>`_.  On the one hand, this case
-provides confidence that existing subinterpreter support is relatively
+`mod_wsgi <https://github.com/GrahamDumpleton/mod_wsgi>`_,
+`OpenStack Ceph <https://github.com/ceph/ceph/pull/14971>`_, and
+`JEP <https://github.com/ninia/jep>`_.  On the one hand, these cases
+provide confidence that existing subinterpreter support is relatively
 stable.  On the other hand, there isn't much of a sample size from which
 to judge the utility of the feature.
 
@@ -613,8 +614,8 @@ Provisional Status
 The new ``interpreters`` module will be added with "provisional" status
 (see PEP 411).  This allows Python users to experiment with the feature
 and provide feedback while still allowing us to adjust to that feedback.
-The module will be provisional in Python 3.7 and we will make a decision
-before the 3.8 release whether to keep it provisional, graduate it, or
+The module will be provisional in Python 3.8 and we will make a decision
+before the 3.9 release whether to keep it provisional, graduate it, or
 remove it.
 
 
@@ -696,13 +697,13 @@ The module also provides the following class:
       threads), there is no return value.  If any value is needed, pass
       it out via a channel.
 
-      The big difference is that "run()" executes the code in an
-      entirely different interpreter, with entirely separate state.
-      The state of the current interpreter in the current OS thread
-      is swapped out with the state of the target interpreter (the one
-      that will execute the code).  When the target finishes executing,
-      the original interpreter gets swapped back in and its execution
-      resumes.
+      The big difference from functions is that "run()" executes the
+      code in an entirely different interpreter, with entirely separate
+      state.  The state of the current interpreter in the current OS
+      thread is swapped out with the state of the target interpreter
+      (the one that will execute the code).  When the target finishes
+      executing, the original interpreter gets swapped back in and its
+      execution resumes.
 
       So calling "run()" will effectively cause the current Python
       thread to pause.  Sometimes you won't want that pause, in which