[Python-Dev] Issues with PEP 482 (1)
Guido van Rossum
guido at python.org
Tue Apr 28 22:06:47 CEST 2015
On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon <mark at hotpy.org> 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.
>
So here's *my* motivation for this. I don't want the code generator to have
to understand decorators. To the code generator, a decorator is just an
expression, and it shouldn't be required to understand decorators in
sufficient detail to know that *this* particular decorator means to
generate different code.
And it's not just generating different code -- it's also the desire to
issue static errors (SyntaxError) when await (or async for/with) is used
outside a coroutine, or when yield [from] is use inside one.
The motivation is clear enough to me (and AFAIR I'm the BDFL for this PEP
:-).
--
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150428/8254bf6c/attachment.html>
More information about the Python-Dev
mailing list