[Python-Dev] Issues with PEP 482

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