<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 5, 2015 at 3:25 PM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><br></div></div>
Yes, there is no other popular event loop for 3.4 other<br>
than asyncio, that uses coroutines based on generators<br>
(as far as I know).<br></blockquote><div><br></div><div>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: <a href="https://github.com/bdarnell/tornado/commit/e3b71c3441e9f87a29a9b112901b7644b5b6edb8">https://github.com/bdarnell/tornado/commit/e3b71c3441e9f87a29a9b112901b7644b5b6edb8</a></div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>-Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
And yes, the PEP is not exclusively intended for use<br>
with asyncio, but asyncio is the only library that ships<br>
with Python, and is Python 3 ready, so its users will be<br>
the first ones to directly benefit from this proposal.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Can I use PEP 492 with Twisted (I doubt it, as Twisted<br>
doesn't use yield from, which is Python 3.x only)? I contend that<br>
there *is* no concrete example that currently exists, so I'm asking<br>
what I'd need to do to write one. You pointed at qamash, but that<br>
seems to be subclassing asyncio, so isn't "something that isn't<br>
asyncio".<br>
</blockquote>
<br></span>
When Twisted is ported to Python 3, I'd be really surprised<br>
if it doesn't allow to use the new syntax.  @inlineCallbacks<br>
implements a trampoline to make 'yields' work.  This is a<br>
much slower approach than using 'yield from' (and 'await'<br>
from PEP 492).  Not mentioning 'async with' and 'async for'<br>
features.  (There shouldn't be a problem to support both<br>
@inlineCallbacks and PEP 492 approach, if I'm not missing<br>
something).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Note that I don't have a problem with there being no existing<br>
implementation other than asyncio. I'd just like it if we could be<br>
clear over exactly what we mean when we say "the PEP is not tied to<br>
asyncio".<br>
</blockquote>
<br>
<br></span>
Well, "the PEP is not tied to asyncio" -- this is correct.<br>
*The new syntax and new protocols know nothing about asyncio*.<br>
<br>
asyncio will know about the PEP by implementing new protocols<br>
where required etc (but supporting these new features isn't<br>
in the scope of the PEP).<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It feels like the truth currently is "you can write your own<br>
async framework that uses the new features introduced by the PEP". I<br>
fully expect that *if* there's a need for async frameworks that aren't<br>
fundamentally IO multiplexors, then it'll get easier to write them<br>
over time (the main problem right now is a lack of good tutorial<br>
examples of how to do so). But at the moment, asyncio seems to be the<br>
only game in town (and I can imagine that it'll always be the main IO<br>
multiplexor, unless existing frameworks like Twisted choose to compete<br>
rather than integrate).<br>
</blockquote>
<br></span>
Agree.  But if the existing frameworks choose to compete,<br>
or someone decides to write something better than asyncio,<br>
they can benefit from PEP 492.<span class=""><font color="#888888"><br>
<br>
<br>
Yury</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ben%40bendarnell.com" target="_blank">https://mail.python.org/mailman/options/python-dev/ben%40bendarnell.com</a><br>
</div></div></blockquote></div><br></div></div>