Tk from IDLE: How to 'Hello World'?
Tk in Windows IDLE does not work the way tutorials suggest. For example, consider Fredrik Lundh's 'Hello World' app at http://www.pythonware.com/library/tkinter/introduction/hello-tkinter.htm Writing it interactively in IDLE, one would go:
from Tkinter import * def test(): root = Tk() w = Label(root, text="Hello, world!") w.pack() root.mainloop()
test()
Which gets you the Tk window saying Hello World, as expected. But then if you hit the close box, do you get back to a working IDLE prompt? I don't. I'm left in limbo, with a prompt I can't go back to. I haven't tested this in LINUX IDLE yet, nor in 1.5.2 -- so maybe this is a new phenomenon with the latest beta? Or is it some problem with my setup? Could another Windows user provide a reality check here? Anyway, Lundh's book and many other resources do not appear to be written with IDLE in mind. For example it states: To run the program, run the script as usual: $ python hello1.py But that's not 'usual' for an IDLE user. There's no $ prompt, and we're already in Python, and so wouldn't invoke it. As someone interested in using Python in schools, I think a GUI like IDLE is a potentially better learning environment than a command line in DOS or Xterm. I would like to see more bias in favor of using IDLE when doing work with Tk (IDLE being itself a Tk app, after all, and cross-platform). Kirby
Tk in Windows IDLE does not work the way tutorials suggest.
As someone interested in using Python in schools, I think a GUI like IDLE is a potentially better learning environment than a command line in DOS or Xterm. I would like to see more bias in favor of using IDLE when doing work with Tk (IDLE being itself a Tk app, after all, and cross-platform).
"IDLE being itself a Tk app" is part of the problem. Without going into a lot of detail: the commands you type into IDLE are executed in the same process as IDLE itself, so you and IDLE share the same "instance" of Tk. This causes a great number of problems, including the one you observe. There may be workarounds for some of them. The right way to solve this and various other problems is to execute your code in a separate process. Guido and Jeremy planned to make IDLE work that way but never got around to it. I modified the version of IDLE included in VPython to do it, but only for scripts, not for interactive mode. We preferred making it easy for students to write and execute short anonymous scripts to emphasizing interactive mode. It is much easier to correct mistakes in a script (since you can go back and edit it, and then easily run it from the beginning). If anyone wants to add remote execution in interactive mode to IDLE, I suggest joining the idle-dev list and contributing to the IDLE fork at http://sourceforge.net/projects/idlefork. That source tree includes my changes, but I no longer have time to work on it. Dave
If anyone wants to add remote execution in interactive mode to IDLE, I suggest joining the idle-dev list and contributing to the IDLE fork at http://sourceforge.net/projects/idlefork. That source tree includes my changes, but I no longer have time to work on it.
Dave
Thanks for spelling this out Dave. I was wondering if I was pushing the envelope vs. what IDLE is able to handle, and you've confirmed my suspicion. I agree with what you say about scripts (easier to debug and so on), but surely you agree that an intuitive IDLE wouldn't care, i.e. it may be a convenience for the user to do Tk stuff only in scripts, but IDLE itself should at least allow interactive function defs with Tk included. It really should be a user option to enter defs right at the command line. Looking through 'Python and Tkinter Programming', I don't find any of these caveats re IDLE (I'll have to go back and check the Python docs, but I don't recall anything there either). Presumably IDLE is kind of "off to the side" and serious development work doesn't involve using it. But a newbie from Windows world isn't necessarily going to know that, especially given IDLE is bundled and is typically the first thing such a user will see (there's no real incentive to use the DOS box environment, given all that IDLE offers). Likewise in the KDE and GNOME shells: IDLE shows up as an IDE, a development environment, in at least some Linux distros (Mandrake in my case). So I think the literture is deficient in not underscoring this rather important limitation: IDLE is not suitable for doing Tkinter programming. That should be stated clearly and up front, if true, lest too many newbies get disillusioned with the experience of non-working code. I realize that it's more the culture to try to dive in and fix (as you've been doing), vs. to sit around and whine about stuff. Point taken. But it would have been a time saver, for me, to know what wasn't going to work in the first place. I want to give realistic assessments of technologies to educators, and if IDLE isn't useful in some respects, I don't like to always learn the hard way. Fortunately, in this case, I haven't already pushed IDLE + simple Tk scripting as a useful learning environment. I'm sure there's a lot of technical fine points that could be made in this area. I don't want to spread misinformation if I have the wrong idea. Kirby
Interesting points about IDLE. Thanks for bringing this clearly the surface. I stopped using IDLE some time ago and started using PythonWin, because as a newbie I found more stuff simply worked first time when I tried it .. being a newbie I was not skilled enough to figure out why IDLE was throwing up at me.. PythonWin has the nice Edit Python Path menu which for newbies is also very helpful. It would be even more helpful it is was documented or had an intro tutorial how to use it. But eventually one finds out. PythonWin will not help anyone not working on Win32 of course so there is still a problem. Which leaves TKinter or wxPython-based tools. Boa looks like it be a good cross-platform IDE for Python, since it allows more experienced Programmers to really extend the feature set with widgets and interfaces targeted at various applications. What it lacks perhaps at the moment is stability and focus for this use. It is a sophisticated multifaceted creature. But for education it looks like it might be a better long-term base than IDLE or PythonWin, because one can really build applications with it. And once students get past the basics they can open up the box itself. Install the Boa folder inside Python/tools. click on boa.py and it launches. At the moment it is rather too confusing with a lot if tabs and windows - not a good for day1.. but those might also be configured to be turned off as newbie defaults. any thoughts? - Jason
participants (4)
-
David Scherer -
Jason Cunliffe -
Kirby Urner -
Kirby Urner