[Python-Dev] PEP 492: async/await in Python; v3

[Stephen J. Turnbull]

Literary critic here.

In section "Specification"

 > 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).

The usual phrasing of "strongly suggested" in specifications is
"presumes knowledge".  Some people think "strongly suggest <do>ing" is
presumptuous and condescending, YMMV.  Also, the relationship to PEP
3152 should be mentioned IMO.  I propose:

    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).

I'm not entirely happy with my phrasing, because there are at least
four more or less different concepts that might claim the bare word
"coroutine":

- this specification
- the implementation of this specification
- the syntax used to define coroutines via PEPs 342 and 380
- the semantics of PEP 342/380 coroutines

In both your original and my rephrasing, the use of "coroutine"
violates your convention that it refers to the PEP's proposed syntax
for coroutines.  Instead it refers to the semantics of coroutines
implemented via PEP 342/380.  This is probably the same concern that
motivated Guido's suggestion to use "native coroutines" for the PEP
492 syntax (but I'm not Dutch, so maybe they're not the same :-).

I feel this is a real hindrance to understanding for someone coming to
the PEP for the first time.  You know which meaning of coroutine you
mean, but the new reader needs to think hard enough to disambiguate
every time the word occurs.  If people agree with me, I could go
through the PEP and revise mentions of "coroutine" in "disambiguated"
style.

In section "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.

Don't invite trouble.<wink />  How about:

    Syntax for asynchronous comprehensions could be provided, but this
    construct is outside of the scope of this PEP.

In section "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.

Same recommendation as for "Comprehensions".  I wouldn't mention the
tentative syntax, it is both obvious and inviting to trouble.


 > Acknowledgments
 > ===============
 > 
 > I thank Guido van Rossum, Victor Stinner, Elvis Pranskevichus, Andrew
 > Svetlov, and Łukasz Langa for their initial feedback.

A partial list of commentators I've found to be notable, YMMV:

Greg Ewing for PEP 3152 and his Loyal Opposition to this PEP.
Mark Shannon's comments have led to substantial clarifications of
    motivation for syntax, at least in my mind.
Paul Sokolovsky for information about the MicroPython implementation.