[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