Fix deprecation warnings for asyncio.get_event_loop() #52
Conversation
In future Python versions, asyncio.get_event_loop() will not create a new event loop as required. As of Python 3.10 it issues a deprecation warning when it has to. This commit changes get_event_loop().run_until_complete() to asyncio.run(), where possible. However, sometimes we need the event loop to stay alive after running a coroutine, so we need to ensure having an event loop manually, similar to how asyncio.run() does.
Codecov Report
@@ Coverage Diff @@
## main #52 +/- ##
==========================================
- Coverage 80.32% 80.29% -0.04%
==========================================
Files 36 36
Lines 4468 4471 +3
Branches 783 783
==========================================
+ Hits 3589 3590 +1
- Misses 718 719 +1
- Partials 161 162 +1
Continue to review full report at Codecov.
|
I hope, this fixes the tests on Python 3.7
|
I'm not sure if this is actually a valid fix for this problem: The Python documentation states, that I'm not sure what's the correct way for running a single coroutine in the thread's existing (but not running) event loop, without closing the loop afterwards. We need to do this in multiple tests. I'm also not sure if it's intended to create an event loop, instantiate a lot of objects, including asyncio.Events and asyncio.Futures, bound to the event loop, and finally starting the event loop. This is how SHC is currently working, but it might be against the Python asyncio developer's intention … |
In future Python versions, asyncio.get_event_loop() will not create a
new event loop as required. As of Python 3.10 it issues a deprecation
warning when it has to.
This commit changes get_event_loop().run_until_complete() to
asyncio.run(), where possible. However, sometimes we need the event loop
to stay alive after running a coroutine, so we need to ensure having an
event loop manually, similar to how asyncio.run() does.