RetroSearch Browse

Tue Apr 28 22:22:39 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-April/139593.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-April/139593.html below:

[Python-Dev] Issues with PEP 482 (1)