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

[Yury Selivanov]

Paul,

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