[Python-Dev] PEP 492: async/await in Python; version 5
ben at bendarnell.com
Wed May 6 06:05:28 CEST 2015
On Tue, May 5, 2015 at 3:25 PM, Yury Selivanov <yselivanov.ml at gmail.com>
> Yes, there is no other popular event loop for 3.4 other
> than asyncio, that uses coroutines based on generators
> (as far as I know).
Tornado supports Python 3.4 and uses generator-based coroutines. We use
`yield` instead of `yield from` for compatibility with Python 2. I have a
patch to support the new async/await syntax here:
Overall, I like the PEP. I've been reluctant to embrace `yield from` for
Tornado coroutines (Tornado's Futures do not implement `__iter__`) because
I'm worried about confusion between `yield` and `yield from`, but async and
await are explicit enough that that's not really a problem.
My one request would be that there be a type or ABC corresponding to
inspect.isawaitable(). Tornado uses functools.singledispatch to handle
interoperability with other coroutine frameworks, so it would be best if we
could distinguish awaitables from other objects in a way that is compatible
with singledispatch. The patch above simply registers types.GeneratorType
which isn't quite correct.
> And yes, the PEP is not exclusively intended for use
> with asyncio, but asyncio is the only library that ships
> with Python, and is Python 3 ready, so its users will be
> the first ones to directly benefit from this proposal.
> Can I use PEP 492 with Twisted (I doubt it, as Twisted
>> doesn't use yield from, which is Python 3.x only)? I contend that
>> there *is* no concrete example that currently exists, so I'm asking
>> what I'd need to do to write one. You pointed at qamash, but that
>> seems to be subclassing asyncio, so isn't "something that isn't
> When Twisted is ported to Python 3, I'd be really surprised
> if it doesn't allow to use the new syntax. @inlineCallbacks
> implements a trampoline to make 'yields' work. This is a
> much slower approach than using 'yield from' (and 'await'
> from PEP 492). Not mentioning 'async with' and 'async for'
> features. (There shouldn't be a problem to support both
> @inlineCallbacks and PEP 492 approach, if I'm not missing
>> Note that I don't have a problem with there being no existing
>> implementation other than asyncio. I'd just like it if we could be
>> clear over exactly what we mean when we say "the PEP is not tied to
> Well, "the PEP is not tied to asyncio" -- this is correct.
> *The new syntax and new protocols know nothing about asyncio*.
> asyncio will know about the PEP by implementing new protocols
> where required etc (but supporting these new features isn't
> in the scope of the PEP).
> It feels like the truth currently is "you can write your own
>> async framework that uses the new features introduced by the PEP". I
>> fully expect that *if* there's a need for async frameworks that aren't
>> fundamentally IO multiplexors, then it'll get easier to write them
>> over time (the main problem right now is a lack of good tutorial
>> examples of how to do so). But at the moment, asyncio seems to be the
>> only game in town (and I can imagine that it'll always be the main IO
>> multiplexor, unless existing frameworks like Twisted choose to compete
>> rather than integrate).
> Agree. But if the existing frameworks choose to compete,
> or someone decides to write something better than asyncio,
> they can benefit from PEP 492.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev