Description
Feature or enhancement
Proposal:
This is an admittedly niche use case, but it's one that we've hit in the development of Toga.
GUI toolkits all have event loops. If you want to use Python asyncio
calls in a GUI app, it is necessary to make the GUI's event loop and Python's asyncio event loop co-exist.
This usually means writing a subclass of EventLoop that overrides run_forever()
in some way. Either the inner while True: _run_once()
loop of run_forever()
needs to be modified to integrate the equivalent "run once" of the GUI's event loop; or the while True
loop needs to be subverted entirely and _run_once()
needs to be invoked regularly on the GUI's event loop.
However, the implementation of run_forever()
makes this difficult to do without duplicating significant portions of the implementation of run_forever()
. For example, Toga's Winforms asyncio integration involves duplicating the startup and shutdown of run_forever()
The fundamental structure of run_forever()
is:
def run_forever():
try:
run_forever_setup()
while True:
run_once()
finally:
run_forever_cleanup()
I propose that the implemenation of run_forever()
be decomposed into exactly these parts - an initial setup, the actual loop, and a post-loop cleanup. This does not impact on the operation of ascynio itself, but it would allow Toga (and any other integrated asyncio loop) to automatically inherit any improvements that are made to the core event loop.
It is worth noting that CPython's own Winforms integration has a similar need. The implementation of run_forever()
in ProactorEventLoop()
needs to include additional setup and additional cleanup calls. Decomposing the base event loop would allow this additional setup and cleanup to be explcit.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
Informal in-person discussion at CPython core team sprint.
Linked PRs
Metadata
Metadata
Assignees
Projects
Status