> On Nov 7, 2016, at 11:08 AM, Yury Selivanov <[email protected]> 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
[email protected]
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
