[Tutor] Re: [Edu-sig] RE: [Idle-dev] IDLE's save-before-run r equirement

[stephen]

> > > What would switching over to using Scintilla accomplish that
> > > sticking with IDLE and continuing it's development wouldn't?
> >
> > In a word "Reuse". That means one editor to maintain for most
> > of the Python IDEs. Add a feature to Scintilla and its pretty
> > trivial for all the IDEs to pick up the new feature without
> > having to reimplemnent it from scratch. Effort gets concentrated
> > on the value add bits rather than the nitty gritty of text editing.
>
> But IDLE has a bunch of requirements that I don't think Scintilla can
> provide.  IDLE has really two editing modes: the regular module/file
> editor, and the "Python Shell".  IDLE's most redeeming feature, IMO,
> is the Python Shell.  Compare editing an interactive session in
> PythonWin's console window with IDLE's Python Shell.  IMO again, IDLE
> is infinitely better, because it uses the exact same editing features
> as the module/file editor, meaning you get proper syntax coloring,
> automatic indentation, call tips, magic expansion; and on top of that
> you get per-line syntax checking, whole-command editing, and history
> recall.  In PythonWin's much more primitive console, it's very easy to
> mess up the input or the output or confuse the auto-indenter.
>
> (I'm an instant gratification person, so Python's interactive mode is
> very important to me.)
>
> I could be wrong about Scintilla not supporting this, but if it did,
> why would PythonWin not use it for *its* console?

Scintilla is just a sophisticated editor component (and it seems to be a 
jolly nice one too). All this talk about using scintilla in IDLE is rather a 
moot point because the fact is it is built on a different gui toolkit to IDLE 
and to have just one part of IDLE (the code editor) based on a different 
toolkit to the rest of IDLE would be just silly. Tearing out just some code 
from IDLE and remaking all of it again with a different gui toolkit just for 
compatibility with a different editing component would also be just silly.

The fact is that the beauty of IDLE, and of its being built in tkinter, is 
that it's small, light and relatively simple and the gui toolkit is available 
by default and working on most platforms python works on. If you 
look back to the earlier parts of the threads that led to here you will find 
this is exactly what many folk, including those in EDU_SIG, are looking for 
from IDLE, and it is the right level and place for the IDE that is bundled in 
the python distribution to be pitched at, particularly the independance from 
third party gui libraries.

In the case of the rather different need for an  IDE that is all singing and 
dancing, there are other projects out there who have this aim (and more are 
starting, if you search for 'python' on sourceforge there seem to be dozens 
of such project in the design or early phases) so there is plenty of scope 
for those who'd like to see something like 'delphi for python' arrive (a 
worthy aim!) to find a project to participate in that is working toward these 
ends. It's a different kind of project for a different end.

I'd like to see the changes from the Vpython guys folded in where appropriate 
(Guido: if they've already implemented running the apps in a different 
process, have they already solved your security problem...?  Vpython guys??) 
and IDLE to definitely keep on moving forward in the track it is already 
following, with no bathwater or babies thrown out. The IDLE editor is quite 
appropriate and suitable for its job in IDLE.

Regards IDLErs,
Stephen.
-- 
<elguavas@users.sourceforge.net>
More power to those who don't care for it.