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

[Guido van Rossum]

On Tue, Apr 28, 2015 at 1:22 PM, Mark Shannon <mark at hotpy.org> wrote:

>
>
> 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.
>

The situation may be different for other Python implementations though. The
minimal changes to the code object are an implementation tactic -- the
syntactic marking of coroutines is fundamental (like in the past the choice
to recognize generators syntactically, albeit in that case by the presence
of yield in their body).


>
>
>> 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?
>

No.

>
>
>> The motivation is clear enough to me (and AFAIR I'm the BDFL for this
>> PEP :-).
>>
> Can't argue with that.
>
> Cheers,
> Mark.
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150428/c1d5fef3/attachment.html>