[Python-Dev] Issues with PEP 482 (original) (raw)

Elvis Pranskevichus elprans at gmail.com
Tue Apr 28 22:22:54 CEST 2015

Hi Mark,

Mark Shannon wrote:

Hi,

I still think that there are several issues that need addressing with PEP 492. This time, one issue at a time :) "async" The "Rationale and Goals" of PEP 492 states that PEP 380 has 3 shortcomings. The second of which is: """It is not possible to natively define a coroutine which has no yield or yield from statements.""" This is incorrect, although what is meant by 'natively' is unclear. A coroutine without a yield statement can be defined simply and concisely, thus: @coroutine def f(): return 1 This is only a few character longer than the proposed new syntax, perfectly explicit and requires no modification the language whatsoever. A pure-python definition of the "coroutine" decorator is given below. So could the "Rationale and Goals" be correctly accordingly, please. Also, either the "async def" syntax should be dropped, or a new justification is required. Cheers, Mark.

As was previously mentioned, new async syntax is a major point of PEP 492.

Coroutine-based concurrent programming is something that a lot of languages and platforms are adopting as a first class feature. Just look at the list of references in the PEP.

While the specific coroutine definition point you are arguing about can certainly be debated about, you seem to disregard the other points PEP 492 is raising, which boil down to making coroutines a first class object in Python, with all the robustness and support that implies. Decorators in Python are an auxiliary feature that has nothing to do with core language semantics.

Also, "async for" and "async with" are just as important in concurrent programs, as regular "for" and "with" are in sequential programs. Saying "no we don't need new syntax", when lots of folks think we do, is just a contradiction without real argument.

                              Elvis

More information about the Python-Dev mailing list