On Monday, October 31, 2016 at 9:49:48 PM UTC+1, Yury Selivanov wrote: > > > Awesome! I’ll reopen that PR in a couple of days. > > Thank you, > Yury
Hi, now that the PR is merged, would like to update asynctest for python 3.6, and I'd like your advice about how get_event_loop() should now be handled. In a nutshell, asynctest.TestCase creates a loop for each test, and adds an option which, when activated, sets a policy which forbids a call to current_policy.get_event_loop() (hence asyncio.get_event_loop()) in the test. The goal of this feature is to assert that a library author will not rely on get_event_loop() when explicit loop passing is required. Now asyncio.get_event_loop() returns the running loop in a callback or coroutine, and this change redefines the recommended practice about explicit loop passing. I'd like to be sure asynctest enforces the right practice, hence, tree options: - the feature is left as it is: a library author should no longer have to deal with the loop from a coroutine/a callback, and this is how asyncio libraries should be written. - the feature should be updated, because explicit loop passing everywhere is the only way to write safe asyncio libraries, we don't know if someone will ever want to make several loop collaborate (= schedule things from one loop to be run on another), - the feature can be deprecated, as there is no reason for someone to still force explicit loop passing. The question can also be: what is now the recommended usage of asyncio.get_event_loop() for asyncio library authors? Thanks for your input!
