[Python-ideas] PEP 525: Asynchronous Generators

Sven R. Kunze srkunze at mail.de
Mon Aug 8 07:44:44 EDT 2016


On 06.08.2016 01:25, Yury Selivanov wrote:
>
> On 2016-08-05 4:51 PM, Sven R. Kunze wrote:
>> Yes, that is how I understand it as well. So, all this complexity 
>> stems from the intertwining of generators and coroutines.
>>
>> I am wondering if loosening the tie between the two could make it all 
>> simpler; even for you. (Not right now, but maybe later.)
>
> Unfortunately, the only way to "loosen the tie" is to re-implement 
> generator protocol for coroutines (make them a separate thing). 
> Besides breaking backwards compatibility with the existing Python code 
> that uses @coroutine decorator and 'yield from' syntax, it will also 
> introduce a ton of work.

You are the best to know that. :)

>>
>> I think that is related to Stefan's question here. I cannot speak for 
>> him but it seems to me the confusion is actually the other way around.
>>
>> Coming from a database background, I prefer redundant-free data 
>> representation. The "a" prefix encodes the information "that's an 
>> asynchronous generator" which is repeated several times and thus is 
>> redundant.
>>
>> Another example: when writing code for generators and checking for 
>> the "send" method, I would then need to check for the "asend" method 
>> as well. So, I would need to touch that code although it even might 
>> not have been necessary in the first place.
>>
>> I don't want to talk you out of the "a" prefix, but I get the feeling 
>> that the information "that's asynchronous" should be provided as a 
>> separate attribute. I believe it would reduce confusion, simplify 
>> duck-typing and flatten the learning curve. :)
>
>
> Thing is you can't write one piece of code that will accept any type 
> of generator (sync or async).
>
> * send, throw, close, __next__ methods for sync generators, they are 
> synchronous.
>
> * send, throw, close, __next__ methods for async generators, they 
> *require* to use 'await' on them.  There is no way to make them 
> "synchronous", because you have awaits in async generators.

There are a lot of things you can do with generators (decorating, adding 
attributes etc.) and none of them require you to "make them synchronous".

> Because of the above, duck-typing simply isn't possible.

See above.

> The prefix is there to make people aware that this is a completely 
> different API, even though it looks similar. 

Sure. So, what do you think about the separate attribute to make people 
aware?


Best,
Sven


More information about the Python-ideas mailing list