[PySide] Heads up: Deprecating asyncio.set_event_loop_policy

[Adrian Herrmann]

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.herrmann at 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-bounces at qt-project.org> im Auftrag von Petr Viktorin <encukou at gmail.com>
Gesendet: Montag, 13. November 2023 10:32
An: pyside at 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 at qt-project.org
https://lists.qt-project.org/listinfo/pyside