[Python-Dev] async/await in Python; v2 (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Wed Apr 22 17:40:27 CEST 2015

Hi Greg,

On 2015-04-22 2:05 AM, Greg Ewing wrote:

Yury Selivanov wrote:

1. COASYNC flag was renamed to COCOROUTINE;

2. sys.setasyncwrapper() was renamed to sys.setcoroutinewrapper(); 3. New function: sys.getcoroutinewrapper(); 4. types.asyncdef() renamed to types.coroutine(); I still don't like the idea of hijacking the generic term "coroutine" and using it to mean this particular type of object.

In my opinion it's OK. We propose a new dedicated syntax to define coroutines. Old approach to use generators to implement coroutines will, eventually, be obsolete.

That's why, in PEP 492, we call 'async def' functions "coroutines", and the ones that are defined with generators "generator-based coroutines". You can also have "greenlets-based coroutines" and "stackless coroutines", but those aren't native Python concepts.

I'm not sure if you can apply term "cofunctions" to coroutines in PEP 492. I guess we can call them "async functions".

2. I propose to disallow using of 'for..in' loops, and builtins like 'list()', 'iter()', 'next()', 'tuple()' etc on coroutines. PEP 3152 takes care of this automatically from the fact that you can't make an ordinary call to a cofunction, and cocall combines a call and a yield-from. You have to go out of your way to get hold of the underlying iterator to use in a for-loop, etc.

On the one hand I like your idea to disallow calling coroutines without a special keyword (await in case of PEP 492). It has downsides, but there is some elegance in it. On the other hand, I hate the idea of grammatically requiring parentheses for 'await' expressions. That feels non-pytonic to me.

I'd be happy to hear others opinion on this topic.

Thanks! Yury

More information about the Python-Dev mailing list