[Python-ideas] PEP 525: Asynchronous Generators

Sven R. Kunze srkunze at mail.de
Mon Aug 8 18:37:26 EDT 2016


On 08.08.2016 19:06, Yury Selivanov wrote:
> You have to be aware of what you're decorating. Always.

You have to be aware of what the decorator does first before you decide 
if it's relevant to be aware of what you're decorating.

> For instance, here's an example of a buggy code:
>
> @functools.lru_cache()
> def foo():
>     yield 123
>
> I'm really against duck typing here.  I see no point in making the API 
> for async generators to look similar to the API of sync generators.

And so do I to making them "almost similar" by putting an "a" in front 
of the well-known generator protocol.

But maybe, because there is not real convincing argument on either side, 
it doesn't matter at all.

> You have to provide a solid real-world example of where it might help 
> with asynchronous generators to convince me otherwise ;)

Something, I learned in the past years is to be prepared. So, such solid 
real-world examples might emerge when async generators are out in the 
wild. Let's hope this does not make it harder for them to start with. :)


> There is a separate attribute already -- __class__.  Plus a couple of 
> new functions in inspect module: inspect.isasyncgenfunction and 
> inspect.isasyncgen.  And the new types.AsyncGeneratorType for 
> isinstance checks.

Got it, thanks.


Just another random thought I want to share:


 From what I've heard in the wild, that most if not all pieces of async 
are mirroring existing Python features. So, building async basically 
builds a parallel structure in Python resembling Python. Async 
generators complete the picture. Some people (including me) are 
concerned by this because they feel that having two "almost the same 
pieces" is not necessarily a good thing to have. And not necessarily bad 
but it feels like duplicating code all over the place especially as 
existing functions are incompatible with async.

As I understand it, one goal is to be as close to sync code as possible 
to make async code easier to understand. So, if dropping 'await's all 
over the place is the main difference between current async and sync 
code, I get the feeling both styles could be very much unified. (The 
examples of the PEP try to do it like this but it wouldn't work as we 
already discussed.) Maybe, it's too early for a discussion about this 
but I wanted to dump this thought somewhere. :)


Thanks,
Sven


More information about the Python-ideas mailing list