python 3.x - `new_root.mainloop()` doesn't make main window unresponsive

Question

Let's say that I have this tkinter script:

import tkinter as tk

def callback():
   new_root = tk.Tk()
   new_root.mainloop()
   print("Done")

root = tk.Tk()

button = tk.Button(root, text="Click me", command=callback)
button.pack()

root.mainloop() 

From my understanding of tkinter, when I press the button, a new window and tcl interpreter should be created. While running callback, the main window (root) shouldn't be updated so it should be unresponsive. new_root.mainloop() is a while True loop that runs until the second window is closed. Therefore, when I press the button it should create a new window, call .mainloop() on it and that should make the main window unresponsive. The problem is that that doesn't happen. The main window is responsive even though code execution is stuck inside new_root.mainloop().

Also closing the second window doesn't print "Done" until the rest of the tkinter windows are closed. Why does that happen?

I looked at the source code for tkinter and _tkinter but I couldn't find anything useful. I have Python 3.7.9, tcl 8.6

Answer 1

Though you're running a subsidiary event loop (really don't do that!) it still shares the same registry of event handlers as the outer loop, so events coming in are handled in the inner loop just as in the outer one. (There's a common piece of low-level event handling code that reaches deep into the OS to do the event processing efficiently. That code, the notifier, is stuff that very few people should ever touch; it's tricky because it merges some really weird and disparate event sources while also working around a bunch of strange bugs on some platforms.) The event_loop method returns once all windows are deleted. It literally calls the low level event processing engine (the API call is Tcl_DoOneEvent()) with appropriate flags, and does that in a while loop (until the number of existing windows drops below 1; that's exactly what it is waiting for). This is why you probably shouldn't count on it terminating and absolutely shouldn't nest it in a GUI callback.