[..]
> 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?

Yury
_______________________________________________
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/

Reply via email to