Hello Petr, Thank you very much for calling this to our attention. If I understand it right, it seems that the replacement will be to use a new optional loop_factory argument that has been introduced for asyncio.run() in Python 3.12): https://docs.python.org/3.12/library/asyncio-runner.html#asyncio.run
Unfortunately, our examples use asyncio.get_event_loop().run_forever() instead of asyncio.run(coro), as the latter approach does not work when we want to keep the event loop running even after the given coroutine finished, which would be the case for a graphical program that waits for user input. I have raised this point in the Python discussion thread. Since we will keep supporting Python versions before 3.12 for a few more PySide versions and also maintain backwards compatibility during this time, the event loop policy will remain for now as we explore the new recommended way of handling this scenario in cooperation with the Python maintainers. I look forward to the continued discussion of this with you and the other maintainers. Best regards, Adrian Herrmann Software Engineer, Qt for Python Qt Group Erich-Thilo-Str. 10 12489 Berlin, Germany adrian.herrm...@qt.io +49 1578 0598682 http://www.qt.io/ Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ________________________________________ Von: PySide <pyside-boun...@qt-project.org> im Auftrag von Petr Viktorin <encu...@gmail.com> Gesendet: Montag, 13. November 2023 10:32 An: pyside@qt-project.org Betreff: [PySide] Heads up: Deprecating asyncio.set_event_loop_policy Hello, The maintainers of `asyncio` are considering deprecation of `asyncio.set_event_loop_policy()`, as it's not needed for IO use cases. This would affect Qt for Python, including [examples/async code] which people presumably reuse in their own projects. It's not entirely clear what the recommended replacement should be. `asyncio` developers could use some help understanding GUI integration use cases. Here's a [relevant comment]: > You could overwrite asyncio.EventLoop but the scary thing there is that it affects all threads. What if I wanted a background thread to continut to just run the original default EventLoop? > > Are those frameworks auto-installing their own policy as a side effect of being imported? Does the policy they install create an event loop of their type for all threads? If so, overwriting EventLoop is not much of a regression. If they are careful to only do something special for the main thread (or for the first event loop created or whatever) we may have to provide a mechanism to set a loop factory per thread, for example. At that point might we not just keep the existing policy system for that purpose, rather than retiring that and inventing something new to replace it? You're welcome to join the discussion at https://github.com/python/cpython/issues/94597 or https://discuss.python.org/t/37553 [examples/async code]: https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/async/eratosthenes/eratosthenes_asyncio.py#n137 [relevant comment]: https://discuss.python.org/t/37553/25 _______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside _______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside
