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
