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.
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. I am tempted to start defending asyncio, but I'll resist, because nothing good can come from that. On Mon, Nov 7, 2016 at 11:41 AM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > On Nov 7, 2016, at 11:08 AM, Yury Selivanov <yseliva...@gmail.com> wrote: > > [..] > > 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". > > 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). > > > The latest update of get_event_loop is a step in the right direction. At > least now we can document the best practices: > > 1. Have one “main” coroutine to bootstrap/run your program; > > 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. > > 3. I want to add “asyncio.main(coro)” function, which would create the > loop, run the “coro” coroutine, and correctly clean everything up. > > What you propose, IIUC is a step further: > > * Deprecate get_event_loop(); > > * Add “current_event_loop()” coroutine. > > This will enforce (1) and (2), making asyncio library devs/users to focus > more on coroutines and async/await. > > Am I understanding this all correctly? > > > Yep. It's not so much making users focus *more* 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. > > -glyph > > _______________________________________________ > Async-sig mailing list > Async-sig@python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/