More uncontroversial updates to PEP 567 (#506)

pep-0567.rst

@@ -22,7 +22,7 @@ correctly keeping track of values per asynchronous task, e.g.
 
 This proposal builds directly upon concepts originally introduced
 in :pep:`550`.  The key difference is that this PEP is concerned only
-with solving the case for asynchronous tasks, and not generators.
+with solving the case for asynchronous tasks, not for generators.
 There are no proposed modifications to any built-in types or to the
 interpreter.
 
@@ -30,7 +30,7 @@ interpreter.
 Rationale
 =========
 
-Thread-local variables are insufficient for asynchronous tasks which
+Thread-local variables are insufficient for asynchronous tasks that
 execute concurrently in the same OS thread.  Any context manager that
 saves and restores a context value using ``threading.local()`` will
 have its context values bleed to other code unexpectedly when used
@@ -39,7 +39,7 @@ in async/await code.
 A few examples where having a working context local storage for
 asynchronous code is desirable:
 
-* Context managers like decimal contexts and ``numpy.errstate``.
+* Context managers like ``decimal`` contexts and ``numpy.errstate``.
 
 * Request-related data, such as security tokens and request
   data in web applications, language context for ``gettext``, etc.
@@ -60,7 +60,7 @@ The proposed mechanism for accessing context variables uses the
 store a context variable should:
 
 * declare a module-global variable holding a ``ContextVar`` to
-  serve as a "key";
+  serve as a key;
 
 * access the current value via the ``get()`` method on the
   key variable;
@@ -70,9 +70,9 @@ store a context variable should:
 
 The notion of "current value" deserves special consideration:
 different asynchronous tasks that exist and execute concurrently
-may have different values.  This idea is well-known from thread-local
-storage but in this case the locality of the value is not always
-necessarily to a thread.  Instead, there is the notion of the
+may have different values for the same key.  This idea is well-known
+from thread-local storage but in this case the locality of the value is
+not necessarily bound to a thread.  Instead, there is the notion of the
 "current ``Context``" which is stored in thread-local storage, and
 is accessed via ``contextvars.get_context()`` function.
 Manipulation of the current ``Context`` is the responsibility of the
@@ -86,7 +86,7 @@ the constructor.
 
 The ``ContextVar.set(value)`` method clones the current ``Context``,
 assigns the ``value`` to it with ``self`` as a key, and sets the
-new ``Context`` as a new current.
+new ``Context`` as the new current ``Context``.
 
 
 Specification
@@ -282,8 +282,8 @@ Every OS thread has a reference to the current ``_ContextData``.
 ``PyThreadState`` is updated with a new ``context_data`` field that
 points to a ``_ContextData`` object::
 
-    PyThreadState:
-        context : _ContextData
+    class PyThreadState:
+        context_data: _ContextData
 
 ``contextvars.get_context()`` is implemented as follows::