[Ubuntu] PyQt5

[Terry Reedy]

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