Per very early in the edu-sig archive, I've always found IDLE both necessary and sufficient for most of my teaching needs, whereas in development I've used Vim (which I suck at), random editors and tools, less Eclipse than you might think, Wing. However, for quick scripts, IDLE works on the job as well, especially in Akbar font. What frustrates me in class though, is I'll get low on the projected screen, having entered a bunch of session variables, identified a lot of stuff, and then I'm sort of stuck to the lower edge, unable to wipe to the top and/or mouse blank command line to the top (drag operation). What's great about IDLE over say IPython is how mouse friendly it is, so easy to dive-bomb into a function def 100 lines back in time and bring it down (into the present), for revisions. You'll understand why I'm so comfortable with this approach if you understand my heritage as a dBase programmer. I think some newcomers to snake charming might be surprised how many of us came up through the pre open source ranks using xBase, which at one time Microsoft touted as the third of three pillars, VB and C/C++ the other two. Those were the bad old days before Unix swept the world by storm in the form of GNU Linux and we got access to true agiles. But not everything about those days was a waste of time. We couldn't have gotten "here" without some kind of "there" there. I think the future of IDLE (if I may speculate idly) will involve getting those plug-ins for non Latin-1 keyboards to drive iconic glyph-making on screen. As to Python itself, I've been wondering allowed whether __op__ = [klingon symbol] would be too terrible, or some other mechanism for opening the operator overloading mechanism to arbitrary Unicode symbols, without proliferating the number of special names in some out of control fashion (i.e. you don't want a __[symbol]__ for each possible symbol we might be tempted to repurpose). Perhaps the more attractive option, consistent with my disdain for "open oh" in place of __mul__, would be to restrict to these few operators, and suggest developers disabuse themselves of the notion that "more is better" in the case of operators to overload. Not only do you not *need* more than but a few (given how generic their capabilities -- as Guido just pointed out, you can pervert / to implement * if you care to, or just go __mul__ = __div__) but you should curb your *want* for that many. Think of your readers for a change. I'd be interested in what other teachers are doing when it comes to projecting Python in front of the class and rattling stuff out in a shell (not just showing scaffolding). When we get low on the screen, kids in the back have a harder time seeing. Yet we want that dBase-style chronology (characteristic of most shells, bash included) and mouse friendliness, something more like a canvas, less like a teletype. Finally, as someone with bookkeeping heritage, I like shells which "preserve mistakes" in the sense of keeping transactions on file, almost like patches and diffs in a version control system. You don't want to be able to "change the past in the past" once you've got a time sequence going, as that's not reflective of real time experience, so breaks the metaphor. If you had a typo at 2:30 PM, just copy it down to 3:00 PM and edit it, don't pretend you got it right the first time. IDLE is like that. Kirby