pep-0492: Incorporate some feedback from Stephen J. Turnbull.

pep-0492.txt

@@ -60,9 +60,11 @@ This proposal introduces new syntax and semantics to enhance coroutine
 support in Python, it does not change the internal implementation of
 coroutines, which are still based on generators.
 
-It is strongly suggested that the reader understands how coroutines are
-implemented in Python (PEP 342 and PEP 380).  It is also recommended to
-read PEP 3156 (asyncio framework) and PEP 3152 (Cofunctions).
+This specification presumes knowledge of the implementation of
+coroutines in Python (PEP 342 and PEP 380).  Motivation for the syntax
+changes proposed here comes from the asyncio framework (PEP 3156) and
+the "Cofunctions" proposal (PEP 3152, now rejected in favor of this
+specification).
 
 From this point in this document we use the word *coroutine* to refer
 to functions declared using the new syntax.  *generator-based
@@ -1114,18 +1116,15 @@ points, making it harder to reason about the code.
 Comprehensions
 --------------
 
-For the sake of restricting the broadness of this PEP there is no new
-syntax for asynchronous comprehensions.  This should be considered in a
-separate PEP, if there is a strong demand for this feature.
+Syntax for asynchronous comprehensions could be provided, but this
+construct is outside of the scope of this PEP.
 
 
 Async lambdas
 -------------
 
-Lambda coroutines are not part of this proposal.  In this proposal they
-would look like ``async lambda(parameters): expression``.  Unless there
-is a strong demand to have them as part of this proposal, it is
-recommended to consider them later in a separate PEP.
+Syntax for asynchronous lambda functions could be provided, but this
+construct is outside of the scope of this PEP.
 
 
 Performance