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. 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." > '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. -- ~Ethan~ _______________________________________________ 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
