<div dir="ltr"><div><div>I would caution against rushing into anything rash here. Nathaniel's post will stand as one of the most influential posts (about async I/O in Python) of this generation, and curio is a beacon of clarity compared to asyncio. However, asyncio has a much bigger responsibility at this point, as it's in the stdlib, and it must continue to support its existing APIs, on all supported platforms, whether we like them or not.<br><br></div>I would love to see a design for a new API that focuses more on coroutines. But it should be a new PEP aimed at Python 3.7 or 3.8.<br><br></div>I am tempted to start defending asyncio, but I'll resist, because nothing good can come from that.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 11:41 AM, Glyph Lefkowitz <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com" target="_blank">glyph@twistedmatrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Nov 7, 2016, at 11:08 AM, Yury Selivanov <<a href="mailto:yselivanov@gmail.com" target="_blank">yselivanov@gmail.com</a>> wrote:</div><br class="m_-9192066167370012906Apple-interchange-newline"><div><div>[..]<br><blockquote type="cite">Sorry, this was a bit tongue in cheek.  This was something I said to Guido at the *very* beginning of Tulip development, when asked about mistakes Twisted has made: "don't have a global event loop, you'll never get away from it".<br><br>I still think getting rid of a global loop would always be an improvement, although I suspect it's too late at this point.  `await current_event_loop()` might make more sense in Asyncio as that's not really "global", similar to Curio's trap of the same design; however, I assume that this was an intentional design disagreement for a reason and I don't see that reason as having changed (as Yury indicates).<br></blockquote><br>The latest update of get_event_loop is a step in the right direction. At least now we can document the best practices:<br><br>1. Have one “main” coroutine to bootstrap/run your program;<br><br>2. Don’t design APIs that accept the loop parameter; instead design coroutine-first APIs and use get_event_loop in your library if you absolutely need the loop.<br><br>3. I want to add “asyncio.main(coro)” function, which would create the loop, run the “coro” coroutine, and correctly clean everything up.<br><br>What you propose, IIUC is a step further:<br><br>* Deprecate get_event_loop();<br><br>* Add “current_event_loop()” coroutine.<br><br>This will enforce (1) and (2), making asyncio library devs/users to focus more on coroutines and async/await.<br><br>Am I understanding this all correctly?<br></div></div></blockquote></div><br></span><div>Yep.  It's not so much making users focus <i>more</i> on coroutines, as having a way to pass a loop to a coroutine that is explicit (the coro needs to be scheduled on a loop already, so the binding has been explicitly specified) but unobtrusive.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-glyph</div></font></span></div><br>______________________________<wbr>_________________<br>
Async-sig mailing list<br>
<a href="mailto:Async-sig@python.org">Async-sig@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/async-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/async-sig</a><br>
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">https://www.python.org/psf/<wbr>codeofconduct/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>