Hi everyone, I agree that it is a (ahem!) darn good question. =) And the issue Patrick brought up about the many IDE projects "re-inventing the wheel" is a great one as well. One trend I see with open source development is that there are generally many projects being built to solve the same problem, but doing so in slightly different ways. So there is no doubt that there is a lot of 'duplicate' code being written out there, and I feel the various IDE developers out there should really work out some common standards. Of course the issue with open source projects at least is that most of them are built "to scratch an itch", so to speak, so the programmer is focused on meeting his/her needs and issues like compatibility are not often addressed. With regards to IDLE, if I may make a suggestion, I think before we decide on how IDLE is to get where it is going, we should first decide on where it is going. What features should IDLE have? What is the "vision" for IDLE? Will it become a power-IDE with features galore attempting to replace the IDEs out there, or stay clean and simple, like Python itself? Should it be Win/Mac/Linux compatible in one package, or is it OK that the Mac implementation is different? And to pose a question that was brought up on the Edu-sig list last weekend: Should there be "teaching" features built into IDLE to help beginners learn the language? (i.e. IDLE, in "training mode", would pose programming problems and point out mistakes) More importantly, who's going do do all this work?? =) As a stray thought, how easy would it be to have some of these features added "dynamically"? In other words, make features like the color coding and code-folding, or even interactive training, into modules that could be imported by the user. That sort of thing. I think Patrick touched upon this in his earlier message. How much work would this be? Or has this sort of thing already been done? My two cents? I think it would be really cool to advance IDLE to have a built-in "training mode" so that everything you need to get up and running with Python comes "in the box". In a way, the CP4E and IDLE projects could become one and the same! (OK, so maybe this is just a dream, but it's a nice one!) Making a Win/Mac/Linux version seems like a good idea, but I think it depends on how much work it is, or realistically how much work will be put into future versions. The features of the editor itself don't seem to bad too me personally. After playing with a lot of "full-featured" IDEs, I settled with a text editor. (Embarrassingly enough, I did not realize that IDLE was also a script editor - I thought it was only a interpreter!) I found the other IDEs to be big and bulky, and the bigger they were, the more bugs and stability problems they had. Of course, I'm on Windows too, so there are other factors there... =) What do others think? I hope I've not gotten on a soapbox and babbled here. I do have a tendency to do that on occasion... <AHEM!> I'm actually new to all this open-source, mailing list stuff so if I'm breaking etiquette rules or something feel free to tell me! ^_^; Thanks for listening! Kevin Ollivier ----- Original Message ----- From: "Dethe Elza" <delza@alliances.org> To: <idle-dev@python.org>; "Python Edu SIG" <Edu-sig@python.org>; "Python Tutor" <tutor@python.org> Sent: Wednesday, June 20, 2001 7:13 PM Subject: Re: [Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-runrequirement

on 01/6/20 03:58 PM, Patrick K. O'Brien at pobrien@orbtech.com wrote:

...

All I am asking is how do we apply the "one right way" attitude to the IDE situation?

I don't have an answer, but it's a damn good question.

--

Dethe Elza Chief Mad Scientist Burning Tiger Technologies

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

What do others think? I hope I've not gotten on a soapbox and babbled here. I do have a tendency to do that on occasion... <AHEM!> I'm actually new to all this open-source, mailing list stuff so if I'm breaking etiquette rules or something feel free to tell me! ^_^;

Thanks for listening!

Kevin Ollivier

I've always thought IDLE was 98% of what's needed. I like these widgets in other IDEs that prompt you with all the possible class methods when you go >>> foo. -- but that's a bell I can live without. When it comes to teaching in the classroom, I think IDLE is a fantastic tool -- as is. Except it doesn't work on the Mac. But maybe MacPython fills that void (wish wish). The major shortcoming of IDLE seems to be that it doesn't do the Tk stuff in a separate thread, so you quit IDLE when you quit the Tkinter program you're working on. So maybe that's what Guido is talking about re running IDLE as a subprocess -- adding that before opening IDLE development to a larger group. As another poster pointed out, a lot of the GUI-development seems to be moving towards XML-based descriptions -- much as HTML is used to spec out interactive forms, only x100 in power. Perhaps GUI development is too much in flux across the board to try hammering down some cross-platform "one right way" at this point. There will be more shake-outs down the road. The main thing I like about IDLE is you can import modules in shell mode and interact with them in a conversational manner. You can have a lot of persistent handles to your objects, which you can play with -- literally. Basically, the user's mind becomes main(), the outer loop, and you've got persistence for the duration of the session. This is way different from just using an editor, where you have to have all your ducks in a row up front, before you commit the script to the interpreter. I like the free form scratch pad feel of IDLE work, which makes it feel a lot like an OS. I think of the GUIs as various idioms in the toolbox -- like that Glade stuff for Gnome (with which I have no personal experience as yet). Kirby