[Python-Dev] PEP 492: async/await in Python; version 5 (original) (raw)

Ben Darnell 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> wrote:

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: https://github.com/bdarnell/tornado/commit/e3b71c3441e9f87a29a9b112901b7644b5b6edb8

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.

-Ben

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 asyncio".

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 something). 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 asyncio".

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. Yury

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ben%40bendarnell.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150505/47fcd4c2/attachment.html>

More information about the Python-Dev mailing list