different groups of students of different age and background. The manipulation of graphical objects on screen is a useful task for younger students because it is highly motivating and it provides immediate feedback about the correctness of a program's logic.

To be successful with younger students, Python needs both a straightforward development IDE and tight integration with a cross-platform GUI library that covers Mac, Windows and Linux. I've not done GUI development with Python

I'm not sure I agree with Jim that tight integration with a cross-platform GUI is essential. Python is very good as a "glue language" that finds ways to establish working, collaborative relationships with a lot of other tools (Tk is one such). I think this is a feature, not a bug, and it inspires kids to look beyond Python, and to think in terms of using one software tool to control another. That's useful. When it comes to graphical output, I use Python with a freeware ray tracer called Povray (www.povray.org). I've done lots of graphics in this way, and melded their production with a more formal presentation of geometry/algebra concepts (as per previous posts). But at no point have I felt a strong need to code a GUI in support of my curriculum. IDLE itself is a GUI of course, and I'm all in favor of having kids code using some intelligent interface that automatically color-codes key words, does other housekeeping. But we already have this in several forms -- and yes, there's always room to make it better. What I would never give up, in my ideal learning environment, is an interactive command line. But you can get that with Python in Linux or DOS in a terminal window, and still make do.[1] I'm going back to my original theme: I think we dilute the potential if we just dream and scheme about what Python could or should be, that it isn't already.[2] I'm sure Python will continue to evolve, but it's something that we could be phasing into more learning environments right now, today -- with 0.0 enhancements. Posts which use this ("immediate suitability") as a premise are more interesting to me at least, even if I dream of a unicode implementation that allows native Thai speakers to do all their coding using the Thai character set (same engine, alternative non-ASCII fonts with renamed key words). I think putting out ideas about how Python needs to be tweeked (or even overhauled) in this or that way, before knuckling down to the real work of integrating it into the curriculum, is to let oneself off the hook to easily. It's like saying "3 years from now, when Python X.X comes out, then maybe we can...". I really don't have much interest in such speculations, personally. Python is a nifty little package right now. More teachers should be aware of the potential. Ideas about how we need to "improve" it fail to answer their need, which is for solutions they can implement today, not tomorrow. Just my two cents. Kirby [1] PS: I highly recommend the small, slim paperback "In the Beginning was the Command Line" by Neal Stephenson, author of the best-selling 'Cryptonomicon'. It's about the history of OSs, weaving together lots of metaphors about culture (borrows a lot from H.G. Wells). Not just somebody getting on a soap box and venting their pet peeves -- way more informative than that. Gives another perspective on GUIs though, and gives ammo to those who think a command line is a great place to cut teeth, if you really plan to grow up as more than just an "end user" of other people's code. [2] "Re recent posts, my operating assumption is there's no time to change the language. Case sensitivity and the interface are just the way they are. http://www.python.org/pipermail/edu-sig/2000-February/000015.html

I may not have been clear in my original post. I am arguing that a well-integrated *GUI framework* for Python that allows students to create GUI elements in their own programs is both pedagogically desirable and essential for Python's success as a general-purpose teaching language in the long term.

Jim -- I think you were clear. We're just talking about graphical front ends versus back ends. Command line Python can be used to create rich "3D worlds" (using VRML, Povray, Alice or whatever) but people are used to that "control panel look" which gives their application a GUI. From their point of view "real programming" includes GUI design and implementation (and they're right of course -- it does). I've written GUIs that run real time during open heart surgery, others for a Food Bank, an Urban League. There's a whole art and a science to GUI design -- but is it really essential to get into all that in conjunction with using Python in the curriculum? I think not. Let me explain.... As a curriculum writer, it's not necessarily my goal, when using Python, to teach programming or good program design (Matthius is from a different school entirely on this point -- and we need his school too). My goal is to elucidate concepts in other disciplines (such as mathematics) by taking advantage of the user-friendly access Python provides to the inner guts of the CPU -- where I can take advantage of "cheap, in bulk" operations. My focus is the knowledge domain (e.g. geometry, number theory, the calculus, philosophy), and not on Python per se. The reality is classrooms are stuck with calculators, and it's silly to move to a computer if all you get is a scientific calculator on the screen (a graphical version of the TI). If we're going to overcome this incredible bias in favor calculators (and to the exclusion of computers), we need a way to give students immediate access to the power of a command line environment. Right away, you can start working with character and string data, long integers (OK, maybe DERIVE can do characters -- I know it handles long integers). Calculators can't do that. Plus you can start outputting scripts ready to drive a ray tracer (colorful "3D" polyhedra, just minutes away). Calculators can't do that. OK, I see why we're using a computer, and not a calculator. And even though programming a calculator is possible in some models, using Python to do is is actually MUCH easier. Case closed: we should have been using more computers in math class years ago.[1] But as soon as you move into GUI design or the theory of tail recursive function calls, you've started to lose this focus. As a teacher phasing Python into a math context, I have some interest in presenting Python in a good light, by showing fairly intelligent examples of working code (so I appreciate Tim's use of a dictionary to streamline the Fibbo algorithm). But my students are mostly looking beyond efficiency issues to the underlying mathematics (notice my remark about mathematicians having no problem with n!/k!(n-k)! -- even though that's just a fancy way to "cancel" many of n!'s digits ("efficiency" is in the notation, not in clock cycles (part of why my Python "notation" contained no error checking for illegal parameters -- do math notations do this?)). Python is just another way of expressing concepts they're already learning, and that we've taught for decades without any programming language at our elbow <shudder>. They are using a programming language, yes, but not to write full blown applications or to understand all the fundamentals of application design -- that'd be another course of study entirely.[2] Kirby Note: [1] Also under the category of "user friendly" I include/ weigh the fact that Python is cross-platform and free. Sometimes teachers as me "what about Mathematica?". I say "Mathematica is a great program. You might find MathCad easier if you don't need all that power. But you can give your students valuable experience in any powerful command line environment -- both Python and DrScheme provide this for free". IE, let's not assume that schools have any real budget for this kind of thing. Maybe they will down the road, but right now, Python is an ideal "foot in the door" kind of language (remember, BASIC was so successful in a lot of ways simply because it was ROM-coded in the early PC chips -- you didn't need to buy anything extra). [2] I was at one time a full-time classroom math teacher at the high school level, plus I've worked in the math and computer literacy text book section of McGraw-Hill. I've taught in the talented and gifted program for Portland Public Schools (in a program that allowed non-union outsiders like myself to participate -- details on request) and presented state-of-the-art math content to public school teachers from all over Oregon at the 1997 Math Summit at Oregon State University. I am currently doing pioneering work via my Oregon Curriculum Network, with offices in Portland. I have a BA from Princeton University and my thesis was entitled 'Some Thoughts on the Philosophy of Ludwig Wittgenstein' (Dr. Richard Rorty was my advisor). However, I am not currently a classroom teacher, so when I write about "my students" I'm talking about a full age range of kids and adults who engage with me over the internet -- more of a distance learning kind of environment.