Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Terry Reedy <tjreedy@udel.edu>
Newsgroups: comp.lang.python
Subject: Re: [Ubuntu] PyQt5
Date: Mon, 9 Nov 2015 05:24:43 -0500
Lines: 65
Message-ID: <mailman.167.1447064719.16136.python-list@python.org>
References: <d453cf4b-7a30-4b2c-9bff-53d488552671@googlegroups.com> <7056c802-308b-4d5c-961d-052ef2671633@googlegroups.com> <n1okg2$da7$1@ger.gmane.org> <201511090241.tA92f7jZ008906@fido.openend.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <201511090241.tA92f7jZ008906@fido.openend.se>
Precedence: list
Xref: csiph.com comp.lang.python:98508

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