Feature or enhancement

Proposal:

This is an admittedly niche use case, but it's one that we've hit in the development ofToga.

GUI toolkits all have event loops. If you want to use Pythonasyncio 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 overridesrun_forever() in some way. Either the innerwhile True: _run_once() loop ofrun_forever() needs to be modified to integrate the equivalent "run once" of the GUI's event loop; or thewhile True loop needs to be subverted entirely and_run_once() needs to be invoked regularly on the GUI's event loop.

However, the implementation ofrun_forever() makes this difficult to do without duplicating significant portions of the implementation ofrun_forever(). For example,Toga's Winforms asyncio integration involves duplicating thestartup andshutdown ofrun_forever()

The fundamental structure ofrun_forever() is:

defrun_forever():try:run_forever_setup()whileTrue:run_once()finally:run_forever_cleanup()

I propose that the implemenation ofrun_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 ofrun_forever() inProactorEventLoop() 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

• gh-110771: Decompose run_forever() into parts #110773