[Python-Dev] PEP 492 and types.coroutine

[Yury Selivanov]

On 2015-05-02 2:14 PM, Ethan Furman wrote:
> On 05/02, Yury Selivanov wrote:
>> On 2015-05-02 1:04 PM, Ethan Furman wrote:
>>> If I'm understanding this correctly, type.coroutine's only purpose is to add
>>> a flag to a generator object so that await will accept it.
>>>
>>> This raises the question of why can't await simply accept a generator
>>> object?  There is no code change to the gen obj itself, there is no
>>> behavior change in the gen obj, it's the exact same byte code, only a
>>> flag is different.
>> Because we don't want 'await' to accept random generators.
>> It can't do anything meaningful with them, in a world where
>> all asyncio code is written with new syntax, passing generator
>> to 'await' is just a bug.
> And yet in current asyncio code, random generators can be accepted, and not
> even the current asyncio.coroutine wrapper can gaurantee that the generator
> is a coroutine in fact.

This is a flaw in the current Python that we want to fix.
>
> For that matter, even the new types.coroutine cannot gaurantee that the
> returned object is a coroutine and not a generator -- so basically it's just
> there to tell the compiler, "yeah, I really know what I'm doing, shut up and
> do what I asked."

Well, why would you use it on some generator that is not
a generator-based coroutine?
>
>> 'types.coroutine' is something that we need to ease transition
>> to the new syntax.
> This doesn't make sense -- either the existing generators are correctly
> returning coroutines, in which case the decorator adds nothing, or they
> are returning non-coroutines, in which case the decorator adds nothing.
>
> So either way, nothing has been added besides a mandatory boiler-plate
> requirement.

It's not nothing; it's backwards compatibility.  Please read
https://www.python.org/dev/peps/pep-0492/#await-expression

@types.coroutine marks generator function that its generator
is awaitable.

Yury