<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 5, 2015 at 2:01 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 May 2015 at 21:00, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br>
> On 2015-05-05 3:40 PM, Jim J. Jewett wrote:<br>
>><br>
>> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.<br>
>><br>
>> Where are the following over-simplifications wrong?<br>
>><br>
>> (1)  The PEP is intended for use (almost exclusively) with<br>
>> asychronous IO and a scheduler such as the asynchio event loop.<br>
><br>
> Yes. You can also use it for UI loops.  Basically, anything<br>
> that can call your code asynchronously.<br>
<br>
</span>Given that the stdlib doesn't provide an example of such a UI loop,<br>
what would a 3rd party module need to implement to provide such a<br>
thing? Can any of the non-IO related parts of asyncio be reused for<br>
the purpose, or must the 3rd party module implement everything from<br>
scratch?<br>
<br>
To me, this is an important question, as it cuts directly to the heart<br>
of the impression people have that coroutines and async are "only for<br>
asyncio".<br>
<br>
I'd be interested in writing, for instructional purposes, a toy but<br>
complete event loop. But I'm *not* really interested in trying to<br>
reverse engineer the required interface.<span class="HOEnZb"></span><br></blockquote></div><br></div><div class="gmail_extra">This is a great idea. What kind of application do you have in mind?<br><br></div><div class="gmail_extra">I think the main real-life use case for using coroutines with a UI event loop is newer Windows code. C# (and IIUC VB) has coroutines very much along the lines of PEP 492, and all code that does any kind of I/O (whether disk or network) must be written as a coroutine. This requirement is enforced by the C# compiler: the basic system calls for doing I/O are coroutines, and in order to get their result you must use an await expression, which in turn may only be used in a coroutine. Thus all code that may invoke an I/O call ends up being a coroutine. This is exactly the type of constraint we're trying to introduce into Python with PEP 492 (except of course we're not making all I/O primitives coroutines -- that would be madness, we're going with optional instead).<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>