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

[Yury Selivanov]

Hi Stephen,

Thanks a lot for the feedback and suggestions. I'll apply them
to the PEP.

On 2015-04-28 11:03 PM, Stephen J. Turnbull wrote:
> 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).

Your wording is 100% better and it's time to mention PEP 3152
too.

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

I also like Guido's suggestion to use "native coroutine" term.
I'll update the PEP (I have several branches of it in the repo
that I need to merge before the rename).

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

Agree. Do you think it'd be better to combine comprehensions
and async lambdas in one section?

>
>
>   > 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:

Sure!  I was going to add everybody after the PEP is
accepted/rejected/postponed.

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

Thanks!
Yury