[Tutor] [Edu-sig] [Idle-dev] IDLE's save-before-run requirement

[Kurt B. Kaiser]

Guido van Rossum <guido@digicool.com> writes:
 
> 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.)

An update of a post to idle-dev, made a couple of days ago:
IDLE is a very useful IDE for Python which has a unique set of features
compared to other solutions:

1. Open souce
2. Under ultimate control of GvR.
3. Portable via Tkinter.
4. Very usable by relatively inexperienced people.
5. Has a Python debugger.
6. Understands Python syntax and environment.
7. Provides an extended example of Python programming.
8. Distributed with most versions (no Mac because of current Tk limitations) 
   of Python at very reasonable cost, so available to first time, casual,
   or resource limited users.
9. Interactive shell has same features as module editor, e.g. colorizing

IMHO IDLE should remain at roughly the (apparent) level of complexity it's at
(or less?) to avoid reducing its usability for beginning/intermediate
programmers.  There are some things which can be done to further improve
usability and reliability, IMHO, like running the target code in a separate
process.

When people involved with Scheme, Forth, or Eiffel are looking for projects,
they tend to re-implement the language. Thank heavens that's not a major factor
with Python, thanks to GvR's leadership. But Pythonistas are clearly attracted
to implementing IDEs!

I can't see any reason why IDLE development should get tied in knots trying for
compatibility with other IDEs. That kind of thing can paralyze you! 

The plan last August, met with enthusiam at the time, was to continue to
develop IDLE on a separate fork to avoid the bottlenecks of new feature patch
review on the Python CVS. The hope was to merge back into the main branch in
the future. If that is to happen, we need to stay close to Guido's vision for
IDLE. When it comes to IDEs, there is more than one way to do it, but Guido has
shown us his way, and I'd vote for continuing along those lines.

With open source software, it appears to be extremely difficult to specify a
project via group interaction.  As just one example, take a look at LispOS
(archived at lists.tunes.org/archives/lispos).  A couple of dozen people argued
specs for nearly two years without any progress.  (Then a student at Utah
implemented in less than 10 hours a first cut at essentially what the LispOS
project was attempting and the project shut down.)  It appears that an initial
implementation is necessary, which can then be enhanced. Python does it by
formal PEP, GvR is suggesting a more informal approach for IDLE: simple
discussion on the idle-dev list.  IMHO, that will work for incremental change.
But as with PEPs, if the group response is favorable, the proposer is still
responsible for coding up a patch for evaluation.

Regards, KBK