[PySide] Heads up: Deprecating asyncio.set_event_loop_policy

Petr Viktorin encukou at gmail.com
Mon Nov 13 10:32:16 CET 2023

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 

[examples/async code]: 
[relevant comment]: https://discuss.python.org/t/37553/25

More information about the PySide mailing list