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

Yury Selivanov yselivanov.ml at gmail.com
Wed May 6 00:25:59 CEST 2015


On 2015-05-05 5:54 PM, Paul Moore wrote:
> On 5 May 2015 at 22:38, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> n 2015-05-05 5:01 PM, Paul Moore wrote:
>>> On 5 May 2015 at 21:00, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>>>> On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
>>>>> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated
>>>>> PEP492.
>>>>> Where are the following over-simplifications wrong?
>>>>> (1)  The PEP is intended for use (almost exclusively) with
>>>>> asychronous IO and a scheduler such as the asynchio event loop.
>>>> Yes. You can also use it for UI loops.  Basically, anything
>>>> that can call your code asynchronously.
>>> Given that the stdlib doesn't provide an example of such a UI loop,
>>> what would a 3rd party module need to implement to provide such a
>>> thing? Can any of the non-IO related parts of asyncio be reused for
>>> the purpose, or must the 3rd party module implement everything from
>>> scratch?
>> The idea is that you integrate processing of UI events to
>> your event loop of choice.  For instance, Twisted has
>> integration for QT and other libraries [1].  This way you
>> can easily combine async network (or OS) calls with your
>> UI logic to avoid "callback hell".
> We seem to be talking at cross purposes. You say the PEP is *not*
> exclusively intended for use with asyncio. You mention UI loops, but
> when asked how to implement such a loop, you say that I integrate UI
> events into my event loop of choice. But what options do I have for
> "my event loop of choice"? Please provide a concrete example that
> isn't asyncio.

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

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

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


More information about the Python-Dev mailing list