[Async-sig] Some thoughts on asynchronous API design in a post-async/await world

Glyph Lefkowitz glyph at twistedmatrix.com
Mon Nov 7 13:38:16 EST 2016


> On Nov 7, 2016, at 9:56 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
> 
> 
>> On Nov 7, 2016, at 12:50 PM, Brett Cannon <brett at python.org> wrote:
>> 
>> 
>> 
>> On Sun, 6 Nov 2016 at 22:41 Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>> 
>>> On Nov 6, 2016, at 8:20 PM, Brett Cannon <brett at python.org> wrote:
>>> 
>>> For me there are two questions the post raises. One is how do we keep people from tying themselves to any one event loop?
>> 
>> Deprecate, then remove, get_event_loop() :-).
>> 
>> Is there a bug filed for that at https://github.com/python/asyncio?
> 
> I don’t think we need to deprecate get_event_loop().  With https://github.com/python/asyncio/pull/452 merged in 3.6, get_event_loop becomes more predictable.
> 
> Now it’s a documentation issue (I’m trying to work on that) to explain asyncio users not to use it (and where they *do* need to use it).
> 
> I will also open a PR soon to add asyncio.main() function (or asyncio.run()) to further simplify working with asyncio & its documentation.  That should make get_event_loop to disappear for end users.

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).

-glyph



More information about the Async-sig mailing list