On Thu, Apr 30, 2015 at 10:54 AM, Paul Moore
PEP 492 is only meant to make code easier to read and write that's already written to use coroutines (e.g. using the asyncio library, but not
On 30 April 2015 at 18:31, Guido van Rossum
wrote: limited to that).
OK, that's fair. To an outsider like me it feels like a lot of new syntax to support a very specific use case. But that's because I don't really have a feel for what you mean when you note "but not limited to that". Are there any good examples or use cases for coroutines that are *not* asyncio-based? And assuming you are saying that PEP 482 should help for those as well, could it include a non-asyncio example? My immediate reaction is that the keywords "async" and "await" will seem a little odd in a non-asyncio context.
The async/await pair of keywords for coroutines actually stems from C#, where the compiler generates special coroutine suspension code when it sees them, and the type checker verifies that they are used correctly -- await's argument must be something of type async, and await must occur inside a function declared as async. These semantics are very similar to coroutines using yield-from in Python, and I had observed the similarity long before this PEP was written. Most examples of coroutines will be doing some kind of I/O multiplexing, because that's what they're good for. But asyncio is not the only explicit I/O multiplexing system in the Python world. Twisted had yield-based coroutines long before anyone else (they called them InlineCallbacks though) and is likely to support Python 3 and some level of interoperability with asyncio. Note: it's PEP 492, not 482. -- --Guido van Rossum (python.org/~guido)