[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
More information about the Python-Dev mailing list
Wed May 6 00:25:59 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 492: async/await in Python; version 5
- Next message (by thread): [Python-Dev] PEP 492: async/await in Python; version 5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PEP 492: async/await in Python; version 5
- Next message (by thread): [Python-Dev] PEP 492: async/await in Python; version 5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list