pep-550: Fix typos (#336)

pep-0550.rst

@@ -55,10 +55,11 @@ the following generator::
 Decimal context is using a TLS to store the state, and because TLS is
 not aware of generators, the state can leak.  The above code will
 not work correctly, if a user iterates over the ``calculate()``
-generator with different precisions in parallel::
+generator with different precisions one by one using a ``zip()``
+built-in, for example::
 
-    g1 = calculate(100)
-    g2 = calculate(50)
+    g1 = calculate(precision=100)
+    g2 = calculate(precision=50)
 
     items = list(zip(g1, g2))
 
@@ -67,7 +68,7 @@ generator with different precisions in parallel::
     #   first value from g2 calculated with 50 precision.
     #
     # items[1] will be a tuple of:
-    #   second value from g1 calculated with 50 precision,
+    #   second value from g1 calculated with 50 precision (!!!),
     #   second value from g2 calculated with 50 precision.
 
 An even scarier example would be using decimals to represent money
@@ -412,11 +413,11 @@ save a reference to the current execution context when they are
 instantiated.  The have the same implementation of ``.send()`` and
 ``.throw()`` methods.
 
-The only difference is that
-``gi_isolated_execution_context`` is always set to ``True``, and
-is never modified by the interpreter.  ``yield from o`` expression in
-regular generators that are not decorated with ``types.coroutine``,
-is semantically equivalent to ``for v in o: yield v``.
+The only difference is that ``gi_isolated_execution_context``
+is always set to ``True``, and is never modified by the interpreter.
+``yield from o`` expression in regular generators that are not
+decorated with ``types.coroutine``, is semantically equivalent to
+``for v in o: yield v``.
 
 .. figure:: pep-0550-generators.png
    :align: center
@@ -538,7 +539,9 @@ Python
 
 2. ``sys.set_execution_context_item(key, value)``: set
    ``key``/``value`` item for the current Execution Context.
-   If ``value`` is ``None``, the item will be removed.
+   If ``value`` is ``None``, the item will be removed
+   (read more about it in
+   `Why setting a key to None removes the item?`_.)
 
 3. ``sys.get_execution_context()``: return the current Execution
    Context object: ``sys.ExecutionContext``.
@@ -554,8 +557,7 @@ Python
    mutable mapping API, abstracting away the real immutable
    ``PyExecContextData``.
 
-   * ``ExecutionContext()``: construct a new, empty, execution
-     context.
+   * ``ExecutionContext()``: create a new, empty, execution context.
 
    * ``ec.run(func, *args)`` method: run ``func(*args)`` in the
      ``ec`` execution context.  Any changes to the Execution Context
@@ -605,8 +607,8 @@ on the low-level immutable ``PyExecContextData`` object.
 
 6. ``PyExecContext_SetItem`` and ``PyExecContext_GetItem``.
 
-The exact layout ``PyExecContextData`` is private, which allows
-to switch it to a different implementation later.  More on that
+The exact layout of ``PyExecContextData`` is private, which allows
+us to switch it to a different implementation later.  More on that
 in the `Implementation Details`_ section.
 
 
@@ -680,11 +682,11 @@ Generators and Coroutines
 Using a microbenchmark for generators and coroutines from :pep:`492`
 ([12]_), it was possible to observe 0.5 to 1% performance degradation.
 
-asyncio echoserver microbechmarks from the uvloop project [13]_
+asyncio "echo server" microbechmarks from the uvloop project [13]_
 showed 1-1.5% performance degradation for asyncio code.
 
 asyncpg benchmarks [14]_, that execute more code and are closer to a
-real-world application did not exhibit any noticeable performance
+real-world application, did not exhibit any noticeable performance
 change.
 
 
@@ -733,7 +735,7 @@ items, HAMT is a bit slower than Python dict/shallow copy.
 
    Figure 6.  Benchmark code can be found here: [10]_.
 
-Figure 6 below shows comparison of lookup costs between Python dict
+Figure 6 shows comparison of lookup costs between Python dict
 and an HAMT immutable mapping.  HAMT lookup time is 30-40% worse
 than Python dict lookups on average, which is a very good result,
 considering how well Python dicts are optimized.