[Python-Dev] PEP 492: async/await in Python; version 5

[Ben Darnell]

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>