[Python-Dev] Issues with PEP 482 (1)
Mark Shannon
mark at hotpy.org
Tue Apr 28 22:22:39 CEST 2015
On 28/04/15 21:06, Guido van Rossum wrote:
> On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon <mark at hotpy.org
> <mailto: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.
The code generator knows nothing about it. The generated bytecode is
identical, only the flags are changed. The decorator can just return a
copy of the function with modified co_flags.
>
> 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.
Would raising a TypeError at runtime be sufficient to catch the sort of
errors that you are worried about?
>
> The motivation is clear enough to me (and AFAIR I'm the BDFL for this
> PEP :-).
Can't argue with that.
Cheers,
Mark.
More information about the Python-Dev
mailing list