[Idle-dev] Whose fault? IDLE, PyGame, or TKinter?
Andy Sy
Andy Sy" <andy@netfxph.com
Sat, 15 Dec 2001 07:13:56 +0800
Python together with IDLE (or a different
interpreted environment perhaps?) should make
for one of the most excellent environment for
interactive experimentation with graphics APIs
like PyGame and OpenGL. The scripting possibilities
are potentially unlimited.
However, there seem to quite a few, small,
but niggling, issues with interaction with a
graphics window at least under Windoze. Because
PythonWin exhibits very similar (but somewhat worse
iirc) problems, I wonder if the problem is that
Python's threading model itself makes it unsuitable
for this kind of environment (which would be tragic).
I've encountered 2 bugs under IDLE which I'll
mention here:
After doing
>>> import pygame
You can do
>>> pygame.init()
>>> surf=pygame.display.set_mode((200,200))
>>> pygame.display.update()
>>> pygame.quit()
as often as you please. But remove the assignment to
surf and you get an application error on the second
set_mode()! (BUG #1)
Also after each pygame.quit(), IDLE freezes and you
have to right-click on the IDLE entry in the start
menu bar to get it to wake up. (BUG #2)
Pete Shinners has discussed BUG#2 before,
here is the excerpt:
=============================================
> Hmm this is strange, in Win2K SP 1,
> when I do a pygame.quit(), IDLE
> freezes or does not repaint the
> screen. Not until I right click
> (left-click doesn't work) on the
> taskbar button corresponding to the
> IDLE window. Pygame.Quit()'s fault
> or IDLE's fault?
yeah, i just tested this too and got the same results.
i think technically this would be an IDLE problem, but
it is very likely that pygame/SDL is not being very
cooperative also.
i think most of the problem comes from the fact that
tkinter and pygame are both written in a way that they
expect they will be the only part of the program dealing
with windows in their process.
i'm pretty sure this can't really be fixed in the
tkinter/pygame libraries, but would have to be dealt with
in the underlying libraries, tcltk/sdl.
actually. the IDLE editor seems to do a much better job
than pythonwin which seems to always crash and die when
initializing pygame. my guess here is that IDLE is doing
a better job of keeping the interactive interpreter in a
separate thread.
anyways. no real solution for you here, but i don't believe
there are any ongoing offorts to get this fixed up. i'd start
with the IDLE team though, since their app does return, they
might be able to detect the 'freeze' and fix it easily?