Terry J. Reedy <tjre...@udel.edu> added the comment:
Researching 'nested mainloop': the one we are concerned with is in
pyshell.PyShell.readline, currently line 1078.
self.top.mainloop() # nested mainloop()
This was in David Scherer's 'Initial Revision' of 2000 Aug 14 without the
comment. It has since been touched once to add the comment.
2004 Dec 22, KBK, 5c3df35b6b1f48cb48c91b0c7a8754590a694171.
The GUI was hanging if the shell window was closed while a raw_input() was
pending. Restored the quit() of the readline() mainloop().
http://mail.python.org/pipermail/idle-dev/2004-December/002307.html
So no hint of reason.
---
https://stackoverflow.com/questions/17252056/tkinter-nested-mainloop
OP asked about using a nested mainloop for a video player. There is discussion
(dispute) of whether or not this blocked the mainloop. Tkinter expert Bryan
Oakley opined "While it's possible, there is very rarely ever a need to call
it. reason to do it, and what you are trying to do probably won't work the way
you think it will. –"
OP Raoul quoted FL "Event loops can be nested; it's ok to call mainloop from
within an event handler." (dead link to draft version). It is now in mainloop
entry of https://effbot.org/tkinterbook/widget.htm. There is no explanation of
why or what effect.
---
Mark Lutz, Programming Python, discusses recursive mainloop calls as an
alternative way to make modal dialogs, without 'wait' and other setup calls.
In the 3rd edition, displayed by Google Books, the half page is expanded to a
full page (442-443, Example 9-14, PP3E/Gui/Tour/dlg-recursive.py) and he adds
that calling quit() is mandatory (see KBK patch above) and that using 'wait',
etc, is 'probably better'. The latter is what IDLE does. Since 'modal' means
'disable event handling outside the dialog', the intent must be to suspend the
outer event loop, as we see for this issue.
---
While I still think that IDLE should protect user code input in response to
*IDLE's* '>>>' prompt, even more than it does now, I now agree that IDLE should
not do the same with try user *input()* calls. The usability of the latter is
the responsibility of users who write them.
Not blocking thread prints may just be a matter of removing mainloop() and all
corresponding quit() calls. Proper sequencing may be trickier. Tem4.py calls
input() and print() from both main and thread. Run directly with 3.9.0b1, it
results in
thread start
main input: m # wait before entering 'm\n'.
main got: m
thread input: t
thread got: t
What surprised me is 'thread input:' being held up until 'main got' was
printed. Run from IDLE, the result is
thread startmain input:
m
thread input: main got: t
thread got: m
t
This is more jumbled, not less. 'main input:' is printed before the '\n' after
'thread start'. etc. Separating print(...input()) into two statements had no
effect. Neither did removing sleep(.1). We will have to retest after blocking
is removed.
----------
Added file: https://bugs.python.org/file49194/tem4.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
