(This touches a bit on things mentioned in #14111)

I'm looking through the debugger code in IDLE, and now understand that it's essentially trying to make a GUI program act like a command line program. Hence the nested call to mainloop(), when we receive a trace execution callback. This is the equivalent of saying "stop here until I input something, and then continue along" at which point the callback completes and we return to the running program.

Right now, if you run a program with the debugger on, and just hit Go, it's just like you're not running it in the debugger at all.

I've mentioned elsewhere (#15347) that I suspect the nested mainloop is behind some of the instability problems related to quitting when the debugger is active.

But if we don't assume that each time we print where we are we have to wait for input, we can do some more interesting things. Most importantly, we should be able to say "Go", and actually watch our program being executed. In other words, whenever it goes to the next statement, the debugger actually shows that statement, highlights the line in the source file, updates variables, etc. -- all without user interaction. 

Someone can sit back and watch, getting a better understanding of what their program is doing while running. You'd be able to see if a program was stuck in a loop, without necessarily going through it one statement at a time, step by step, or setting breakpoints. 

It also makes it clearer that the program is running because you see something happening... now there's not great feedback in that regard. Similarly, some of the issues with pausing/continuing or stopping the program become a bit easier to deal with.