configure asyncio loop using loop_factory kwarg rather than using the set_event_loop_policy#7969
Conversation
62b9e7d to
1b1fae7
Compare
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 20 files ±0 20 suites ±0 11h 19m 45s ⏱️ + 18m 9s For more details on these failures, see this check. Results for commit 05dfece. ± Comparison against base commit 8e6c287. ♻️ This comment has been updated with latest results. |
c6668dd to
397bbb2
Compare
397bbb2 to
05dfece
Compare
| if loop_factory is None: | ||
| asyncio.set_event_loop(loop) |
There was a problem hiding this comment.
why is this not necessary when using a loop_factory?
There was a problem hiding this comment.
this is the behaviour from 3.11+ when loop_factory was introduced to asyncio.Runner
it isn't called when the loop_factory is specified because otherwise it would call asyncio.get_event_loop_policy().set_event_loop(loop) on the default policy with a loop from another policy which isn't supported
set_event_loop is currently only used by the posix _UnixDefaultEventLoopPolicy to set an eventloop for listening to child process events with a child process watcher, which is deprecated and not used on windows or uvloop where we use the loop_factory kwarg
| if loop_factory is None: | ||
| asyncio.set_event_loop(None) |
|
Nice! Thank you @graingert :) |
Closes #7492
it would be nicer to not need the ProactorEventLoop at all, but there's still some issues using it (see failures in #7494)
This PR backports the new "loop_factory" kwarg for asyncio.run introduced in Python 3.12 and uses it instead of set_event_loop_policy this PR is still useful even if #7494 as this avoids calling uvloop.install which also mutates the global event loop policy
pre-commit run --all-files