Copyedit PEP 567 with small and hopefully non-controversial changes (#503)

pep-0567.rst

@@ -14,14 +14,14 @@ Post-History: 12-Dec-2017
 Abstract
 ========
 
-This PEP proposes the new ``contextvars`` module and a set of new
+This PEP proposes a new ``contextvars`` module and a set of new
 CPython C APIs to support context variables.  This concept is
-similar to thread-local variables but, unlike TLS, it allows
+similar to thread-local variables, but, unlike TLS, it allows
 correctly keeping track of values per asynchronous task, e.g.
 ``asyncio.Task``.
 
 This proposal builds directly upon concepts originally introduced
-in :pep:`550`.  The key difference is that this PEP is only concerned
+in :pep:`550`.  The key difference is that this PEP is concerned only
 with solving the case for asynchronous tasks, and not generators.
 There are no proposed modifications to any built-in types or to the
 interpreter.
@@ -32,17 +32,17 @@ Rationale
 
 Thread-local variables are insufficient for asynchronous tasks which
 execute concurrently in the same OS thread.  Any context manager that
-needs to save and restore a context value and uses
-``threading.local()``, will have its context values bleed to other
-code unexpectedly when used in async/await code.
+saves and restores a context value using ``threading.local()`` will
+have its context values bleed to other code unexpectedly when used
+in async/await code.
 
 A few examples where having a working context local storage for
-asynchronous code is desired:
+asynchronous code is desirable:
 
 * 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.
+  data in web applications, language context for ``gettext``, etc.
 
 * Profiling, tracing, and logging in large code bases.
 
@@ -56,7 +56,7 @@ and ``contextvars.ContextVar``.  The PEP also proposes some policies
 for using the mechanism around asynchronous tasks.
 
 The proposed mechanism for accessing context variables uses the
-``ContextVar`` class.  A module (such as decimal) that wishes to
+``ContextVar`` class.  A module (such as ``decimal``) that wishes to
 store a context variable should:
 
 * declare a module-global variable holding a ``ContextVar`` to
@@ -149,7 +149,7 @@ future.
 
 ``ContextVar`` design allows for a fast implementation of
 ``ContextVar.get()``, which is particularly important for modules
-like ``decimal`` an ``numpy``.
+like ``decimal`` and ``numpy``.
 
 
 contextvars.Context
@@ -158,7 +158,7 @@ contextvars.Context
 ``Context`` objects are mappings of ``ContextVar`` to values.
 
 To get the current ``Context`` for the current OS thread, use
-``contextvars.get_context()`` method::
+the ``contextvars.get_context()`` method::
 
     ctx = contextvars.get_context()
 
@@ -167,7 +167,7 @@ method::
 
     ctx.run(function)
 
-Any changes to any context variables that ``function`` causes, will
+Any changes to any context variables that ``function`` causes will
 be contained in the ``ctx`` context::
 
     var = ContextVar('var')