-
Notifications
You must be signed in to change notification settings - Fork 52
Use asyncio loop_factory instead of policies for python>=3.12 #140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use asyncio loop_factory instead of policies for python>=3.12 #140
Conversation
6511cd5
to
930c53a
Compare
930c53a
to
9ee34a4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please approve CI as well, I want to see how it turns out, that way we can simply merge this day after py314 is released. Thanks!
qasync/__init__.py
Outdated
with _set_event_loop_policy(DefaultQEventLoopPolicy()): | ||
return asyncio.run(*args, **kwargs) | ||
# A run function matching the signature of asyncio.run | ||
def run(main_coro, *, debug=None, loop_factory=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hosaka I tried to mimic the official asyncio.run interface, but is loop_factory
sort of... extra? I mean purpose of using qasync.run is to run with the qasync event loop, not any other ones (use asyncio.run for that, I guess).
@hosaka It seems that the flaky test for x86_64 3.12 qt6 need to be solved, else it will plague more CI runs. |
My CI is approved, but I repent for wasting so much resources because I can't get CI configs right, but there's no way to test CI offline... there's act but I can't seem to sset it up wright. |
I think rather than mimicing asyncio.run (admittedly I also thought we should do it this way), we should adopt using The goal is to preserve the current behaviour of |
So for >3.12 qasync.run can be a simple wrapper for asyncio.run(coro, *args, **kwargs, loop_factory=QEventLoop(QApplication.instance() or QApplication(sys.argv)) |
@hosaka Let's do your proposition for >=3.14. |
I think something like this would be enough, removing all loop policy related code, keeping qasync.run backwards compatible and using asyncio.run for >3.12: def _get_qevent_loop():
return QEventLoop(QApplication.instance() or QApplication(sys.argv))
@contextlib.contextmanager
def _use_event_loop():
old_loop = None
try:
old_loop = asyncio.get_event_loop()
except RuntimeError:
pass
loop = _get_qevent_loop()
asyncio.set_event_loop(loop)
try:
yield
finally:
loop.close()
asyncio.set_event_loop(old_loop)
def run(*args, **kwargs):
if sys.version_info >= (3, 12):
return asyncio.run(*args, **kwargs, loop_factory=_get_qevent_loop)
else:
with _use_event_loop():
return asyncio.run(*args, **kwargs) This passes all the tests, with the exception of adding a skip to @pytest.mark.skipif(sys.version_info < (3, 12), reason="Requires Python 3.12+")
def test_qasync_run_restores_policy(get_event_loop_coro): |
FWIW I'm getting this wwarning
|
We don't use pytest-asyncio |
@hosaka Good to know. I think this is ready, macOS-x86_64 is an intermittent failure that appears quite often that need to get resolved separately; otherwise, let's just wait for Python 3.14 release to and Let's Get This Merged. Would you agree? |
The version check should be agains 3.12, not 3.14. Since Seeing how little these changes actually connected to 3.14, please remove all your changes to |
@hosaka Done, also since CI is failing a lot on TimeoutError, I increased all the 3.0 and 5.0 second timeouts to 10.0 seconds. |
No description provided.