On Tue, May 5, 2015 at 3:25 PM, Yury Selivanov <yselivanov...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ben%40bendarnell.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com