On Tue, Apr 28, 2015 at 1:22 PM, Mark Shannon <m...@hotpy.org> wrote:
> > > On 28/04/15 21:06, Guido van Rossum wrote: > >> On Tue, Apr 28, 2015 at 11:44 AM, Mark Shannon <m...@hotpy.org >> <mailto:m...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
