[Visualpython-users] RE: [Edu-sig] Python Shell - was: RE: IDLE's save-before-run r equirement

[Kirby U. <pd...@te...>]

At 10:57 AM 6/21/2001 -0500, Patrick K. O'Brien wrote:
>Well, the current IDLE is 0.8. So any difference in the Shell
>capability between 0.5 and 0.8 are going to show up.

Absolutely.  But we're just comparing IDLE with itself --
it's not a whole other IDE/shell with VPython, like Pythonwin,
Boa or whatever.

I think ideally the standard IDLE will run user programs in
a different thread (what VPython's version does) and at that
point VPython might be able to stop doing a whole separate
IDLE.  That would seem an appropriate division of labor to
me (let the VPython team get out of the IDE business -- what
a recent post said was happening anyway, owing to time
constraints).  It was just extra work for them, to have to
go to the trouble of doing a separate version of IDLE.

I agree with Kurt B. Kaiser:  IDLE is great IDE to include
in the standard distro and there should *not* be some attempt
to rip out its guts in favor of some Scintilla-based thing
or whatever.  It's too far along, and works too well, to
be overhauled in such a fundamental way.  Tweek the key
bindings and some other things maybe.  Improve it
incrementally.  But don't overhaul from the ground up.

Too bad for Mac users that Tk is broken on that platform.
Maybe this will change with the newer UNIX-based OS?

I think at the heart of the issue is that Python, as a language,
is not GUI-centric, i.e. there's not GUI built in.  What you
have are wrapper/APIs around other languages for your GUI frames
and widgets, be that GNOME, Tk or Microsoft Foundation Classes
(Windows widgets).

In contrast, Java has its own native cross-platform AWT/Swing
classes, so it makes sense to write a Java IDE in pure Java.
The Java language isn't wrapping around something else (yes,
there are peer classes pairing the Java to platform-specific
implementations -- but this isn't the same thing (we're still
'thinking in Java' all the way down to button size and color)).

So when we talk Python IDE, we're talking Python + Something,
and there's no one other language that Python is "best" designed
to work with.  Because Python is ideally suited as a glue language,
which means, by definition, it gets along pretty well with a lot
of others.  So the "one way to do it" concept is coming up against
the "versatile glue language" concept, and I think in the case of
IDEs, it's the versatility that wins.

There's no reason to have just one IDE (certainly that's not
the case in Java world either, or many other worlds -- any
number (and they don't have shell mode because Java, like C,
like Pascal, is not interactive).  However, it is arguable
that there should be one IDE that ships standard with Python
under the same license agreement.  IDLE is currently that IDE,
and I think should continue in that role.

As for everyone standardizing on the same "right" IDE for
their own development work:  it ain't never going to happen,
nor should it.  IDLE is great for learning, has a bright
future in the classroom (where Python is catching on).  But
it doesn't need to be "the" IDE, even if it's the one that
ships as the default, as part of the standard distro (same
with Linux GUIs -- KDE, Gnome... there's no "one right
interface" there either).  It's only in the imperial paradigm
that we standardize at this level (closer to the Microsoft
model).

Kirby