[Edu-sig] IDLE Instabilities Update

[John Zelle]

For those of you who have been having trouble with IDLE hanging 
(especially under Windows), I think one nasty glitch has now been ironed 
out. I posted a bug report on the idle-dev list and got a very prompt 
and thorough reponse from Kurt Kaiser who is apparently responsible for 
much (most?) of the current subprocess communication code. It turns out 
that the problem I found was quite old and not in the subprocess code at 
all, but a fix has now been checked in.

Kurt sent me a patch for the idlelib/PyShell.py file. I have applied it 
against versions 1.03 and 1.1 of IDLE sucessfully. If you are interested 
in using this patch before the next version of Python is released, I 
have put the patch and patched versions of PyShell.py here: 
http://mcsp.wartburg.edu/zelle/IDLE

Kurt believes that IDLE is actually very stable now, and I suspect that 
a lot of the troubles people have been reporting are the result of this 
bug that was  just squashed (at least the problems that I've noticed in 
our lab were). I'd encourage any of you who use IDLE to patch your 
PyShell.py files (or drop in my replacement) and continue using IDLE.

There is one remaining known issue on Windows. Due to a quirk in the 
underlying Windows socket code, it is apparently possible to have 
multiple (partial) starts of IDLE running at the same time, all bound to 
the same socket. This is very bad :-). For the moment, you just need to 
be sure to only have one copy of IDLE running at a time. My standard 
operating procedure is to start IDLE first, and then just load whatever 
files I want to work on. I keep IDLE running for my entire session, and 
have not had any problems.

I'd be interested in hearing any feedback on whether this patch has made 
IDLE more workable for any of you. Also, if you are still finding 
instabilities in IDLE, we should try hard to track them down. At least 
some of the IDLE developers are keenly interested in stability. If we 
can track problems down, I think they will get fixed in realtively short 
order.

Oh, and if you are using my graphics library interactively in IDLE on 
Windows, the graphics window will be unresponsive any time IDLE is 
waiting for input. This is annoying, but I haven't had a chance to 
rework my library yet for the new IDLE (it will probably require 
multiple threads, another topic of recent interest on edu-sig :-).

--John

ps. I came into the "learn to program in 10 years" thread late, so I did 
not bother to post, although there was much there of interest to me. 
Just for the record:

1. I really, really like KDE. IMHO it's better than aqua (honest) so you 
can keep your macs; I'll run on the cheap hardware :-)

2. I have noodled around a bit with PyQT (really should be QTPy don't 
you think ;-), and it seems very nice. The OpenGL widget works as 
advertised, and you can design GUIs with the standard QTdeveloper tools 
and convert to Python boiler plate (or parse them dynamically) much like 
Glade for gtk.

3. There are no license problems at all with QT on any platform, as long 
as you are not developing commercially. On Windows, you do need to 
license the widgets for commercial development (it's free on Linux, not 
sure on Mac).

4. I also want to do some things where VPython is embedded in other apps 
(specifically a Stereo 3D presentation system). However, Vpython is just 
one of several packages that I'd like to use. I am probably going to 
sacrifice portability and use X Window's ability to manipulate other 
windows (ala a window manager or plugger). Hopefully, some work on this 
will happen this Spring.

5. Software patents are ludicrous. Mathematical theorems are not 
patentable, neither should algorithms be. Unfortunately, the USPO has 
gone so far up this wrong road that it's hard to see how we will 
extricate ourselves. Let's hope the EU does the right thing. All of us 
need to keep up the fight on this issue in any small way we can.