[Python-Dev] PEP 492: async/await in Python; v3 (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Wed Apr 29 05:23:46 CEST 2015

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

More information about the Python-Dev mailing list