I think there's a whole new recommendation for library authors. They should just rely on get_event_loop() except under two circumstances:
- When you need a loop but your loop is not yet running. Note that this should be very rare -- e.g. when you're calling a coroutine function like asyncio.sleep() and passing it to another loop (or to run_until_complete()) you do *not* need the loop because the body of the coroutine doesn't start running until it is first scheduled. - When run inside an application, framework or test that explicitly sets the global event loop to None. This should only be a backwards compatibility concern at this point: we should recommend that such apps, frameworks and tests switch to allowing get_event_loop(), *unless* they are bound to backward requirement with the stdlib asyncio in Python 3.4 or 3.5.3 (or old asyncio installations on 3.3). --Guido On Tue, Nov 8, 2016 at 8:07 AM, Martin Richard <mart...@martiusweb.net> wrote: > > > 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! > -- --Guido van Rossum (python.org/~guido)
