On 11/8/2015 9:41 PM, Laura Creighton wrote:
In a message of Sun, 08 Nov 2015 18:05:32 -0500, Terry Reedy writes:
I just read somewhere that the issue could be because I was trying to
run these examples from within Idle.
First let me note that a) IDLE is meant for learning Python and
developing Python programs, and b) IDLE using tkinter/tcl/tk and
programs that introspect too deeply or interact with hardware can
interfere with each other. I recently added
https://docs.python.org/3/library/idle.html#idle-console-differences
to document some differences from console python.
Can IDLE be used for developing GUI programs? In the case of tkinter,
yes. For 3.x, at least, I believe there are advantages over plain
editors. For other gui packages, I would like to know what limitations
or problems there are so I can warn people against trying to do things
that will not work. Hence the questions below.
I am an IDLE maintainer. Am I to take it that everything ran fine
before you tried to quit? If not, I would want to know why and try to fix.
If you run tut.py from an IDLE editor, IDLE tries to run it the same as
if you ran it at a console in the tut.py directory with 'python3 -i
tut.py'. I can imagine that there might be a problem with the
transition from gui mode to interactive shell mode, though it works for
tkinter apps. You said 'python3 tut.py' works. What happens if you add
the '-i' option? I'd like to know if the transition problem is in
(Py)qt5 or in IDLE's simulation of '-i'.
I suspect that Qt and Idle are disagreeing as to who gets to have the
main thread around here.
I doubt this is the specific problem because user code, here invoking
pyqt and qt, are run in a separate process. While it is running, I
believe the only Idle code that would run is in the substitute
stdin/out/err, which are only used if the user code calls input, print,
or .write() or raises. Instead of
> python3 -i mypyqt.py
at a console prompt, IDLE starts a subprocess with
> python -m idlelib.run mypyqt.py
The latter sets up socket communication, a locals namespace that
imitates __main__, and a few other things and then runs
exec(open(mypyqt.py).read(), locals).
I can imagine a few different ways things could get messed up, which is
why I asked the specific questions I did. For instance, if a program
rebinds the standard stream but does not restore them, because it
assumes that exiting the program mean exiting the process (as would
normally be the case with a gui program), then the '-i' option and the
IDLE simulation thereof may not work.
In thinking about this, I realized that I could test that idlelib.run at
least works with all stdlib modules by running the entire CPython test
suite in the execution process. I already run idle tests in IDLE while
developing them, but had never thought about the fact that I was testing
the run module also.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
