Since Tkinter's PyOS_InputHook implementation sets the thread state, we need to ALLOW_THREADS around it. We could either do that in Tkinter (but that would be a new requirement on all PyOS_InputHook implementations in the wild), or instead callPyOS_InputHook through a wrapper that allows threads. I have a proof of concepthere to show what I mean. This seems to make matplotlib and the simpleTkinter reproducer work as expected (events are handled, the window repaints and resizes etc.)

I share@ambv's concern that thisisn't called periodically, but at least for Tkinter it doesn't matter. Maybe it does for other GUI toolkits, though -- it looks likePyQt5 does, for example.

or instead callPyOS_InputHook through a wrapper that allows threads.

I think that's our best approach here because it was previously readline dropping the GIL around it so now is us that need to do it and we must to that from C.

Ok, I think I have a version that should be backwards compatible with the periodic calls thatreadline.c does. It may be still have some rough edges but I want to discuss before doing more with this.@ambv@mdboom

Things that may be useful references:

• IPython's inputhooks (for prompt toolkit)https://github.com/ipython/ipython/tree/main/IPython/terminal/pt_inputhooks
• ipykernel event loop hooks (for tornado, it is a web server, but same theory)https://github.com/ipython/ipykernel/blob/main/ipykernel/eventloops.py
• https://github.com/matplotlib/matplotlib/blob/a833d99e46f5771aee7c25066276a70e6e7b9ef3/src/_macosx.m#L54-L96 /https://github.com/matplotlib/matplotlib/blob/a833d99e46f5771aee7c25066276a70e6e7b9ef3/src/_macosx.m#L191-L202 mpl's PyOS_InptuHook for the macOS UI
• pyqt5 and pyqt6 have implementations, but not sure if you want to look at them due to GPL issues
• pyside's proposed patch (which I am not 100% sure is correct)https://codereview.qt-project.org/c/pyside/pyside-setup/+/454254/2/sources/pyside6/libpyside/pyside.cpp
• Matplotlib's documentation on input hookshttps://matplotlib.org/stable/users/explain/figure/interactive_guide.html#input-hook-integration (if these are wrong I'll fix them)
• discussion of wxPythonhttps://discuss.wxpython.org/t/interactive-usage-of-wxpython/32128/22 but this seems to be lost in the current version (I can not find PyOS_InputHook in the current source and mpl does not work with py312@DietmarSchwertberger (who has worked on both mpl and wxpython) or@RobinD42 may be able to comment on that?
• old bug reports about gtk using PyOS_InputHook (https://stackoverflow.com/questions/32754630/runtimewarning-pyos-inputhook-is-not-available-for-interactive-use-of-pygtk ) but I can not find it in their current source (but also not sure I am even looking at the right place...I do not undrestand how pygobject works) and mpl does not work with py312. I did findhttps://github.com/nzjrs/pygtk/blob/5bee5a7850bbe8ce0581afe8b9a71eaa52d7206b/gtk/gtk.override#L457-L480 but that repo was last touched 13 years ago and looks like a soft-fork of something upstream
• https://github.com/search?q=PyOS_InputHook&type=code&p=1 has a lot of hits

The best-case behavior is when the input hook can watch stdin and exit the event loop when there is input to read, second best case is the hook run the loop for some short period and checks if there is input in a hotloop.

Mike is right, the expect expectation is that the window is reasonably responsive (<100ms) and you can type at the prompt (and it isalso responsive with tab-complete etc). In general the time scale we need to switch between the two loops is human interaction time so it is OK if the prompt does not work while the user is interacting with the GUI so long as the prompt gets control again by the time the user can change their "focus" there (e.g. move mouse and click, then type).

I suspect that I'm going to be making some upstream bug reports to gtk and wx after this...

Taking a very selfish (from Matplotlib's point of view) position, if you want to re-design the input hook so long as tkinter (which I assume you will do ;) ), riverside (for PyQt) (worst case I can try to put in a patch), and Matplotlib (for macos which I can make sure gets done) provide the new hook we will get back to status quo.

It is probably worth testing PyQt5 and PyQt6 (I do not have time to do this today).

I confirm this PR also fixes the matplotlib example given by Michael in the issue on macOS Sonoma.

PyQt is important to us. We'll test it and adjust the behavior if needed. Now I need to land this to make it into 3.13 beta 2.

Thanks@pablogsal for the PR, and@ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

Sorry,@pablogsal and@ambv, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker d9095194dde27eaabfc0b86a11989cdb9a2acfe1 3.13

I'll backport this myself oncegh-120062 lands.

GH-120066 is a backport of this pull request to the3.13 branch.

Thank you@pablogsal@ambv and@mdboom !

@tacaswell

pyside's proposed patch (which I am not 100% sure is correct)https://codereview.qt-project.org/c/pyside/pyside-setup/+/454254/2/sources/pyside6/libpyside/pyside.cpp

This is an earlier version of the patch, in which PyOS_InputHook -> qAppInputHook processes the currently available events, and then returns. This relies on Python calling PyOS_InputHook repeatedly, which is not guaranteed (Python without readline support calls PyOS_InputHook only once per cycle).

Note that in the final accepted version of this patch, PyOS_InputHook -> qAppInputHook waits until input is available on stdin, and then returns. This works on Python with and without readline support. Seehttps://codereview.qt-project.org/c/pyside/pyside-setup/+/454254/9/sources/pyside6/libpyside/pyside.cpp