[Idle-dev] /me waves

[Bruce Sherwood]

(Thanks, Katie and Guido, for explaining about up arrow referring to the
shell.)

I've been busy with other matters during the last few years, so the
following concerns about IDLE development may, I hope, no longer be a
problem.

In the Google Summer of Code 2009 I mentored Guilherme Polo, who made a
number of very important contributions to IDLE. This was a project approved
by the Python community, and there were assurances that Polo's improvements
would become part of the IDLE distributed with official downloads of
Python. Alas, as far as I can tell this didn't happen, apparently because
there was no well-defined path for updating IDLE. So my first concern is
whether it is now the case that if important improvements are made, is
there any chance they would make it into the official Python distributions.
What is the situation today?

Secondly, to check on the current status, I just installed Python 3.3.0 on
Windows and Mac and tried out IDLE. On Windows, judging from the "Configure
IDLE" menu option, IDLE apparently lacks (at least) two significant
features of Polo's work, one vitally important for a large population of
student users. On the Mac, clicking on the Preferences menu option (for
configuring IDLE) causes a crash, but I assume the situation is similar to
that on Windows.

Among many improvements, Polo implemented a feature that if there is an
execution error in a spawned program that creates a window, the shell with
the error message comes forward of that window so that you see the error,
with an IDLE preference for invoking this behavior. The shell does come in
front of the edit window in the case of an execution error, but at least in
older versions of IDLE if running the program creates a new window, and
that window covers the shell window, an execution error doesn't bring the
shell window forward. I couldn't immediately think of a way to test this in
a newly installed Python 3.3.0, but unless this behavior is now the default
and therefore there's no need for a preference setting, presumably this
feature isn't in the currently distributed IDLE.

Why is this feature important? Every year thousands of engineering and
science students who take the required college introductory physics course
and use the textbook "Matter and Interactions" (matterandinteractions,org)
write Python programs to model physical systems, using the VPython 3D
programming environment (vpython.org). Very few of these college students
have ever written a computer program before, and the language (Python), the
3D aspects (VPython), and the program editor (IDLE) must be extraordinarily
easy to learn and use, because in a physics course, where computational
modeling is vitally important, it isn't feasible to teach a lot of computer
science.

It is an experimental fact of life that these students typically make all
of the relevant windows, including the 3D graphics window (based on
OpenGL), huge. When an execution error occurs, the program of course stops,
and the students tend to sit there wondering why the animation has stopped,
because the shell window with its error message is hidden behind the
graphics window. After 12 years deployment of VPython, I can say that it's
easier to improve IDLE than to modify student behavior.

Incidentally, VPython is downloaded about 60,000 times per year, and about
10,000 of those downloads occur at the start of the two US college
semesters, clearly by students who use VPython in their classes. VPython is
also used by researchers who need an easy programmatic access to making 3D
animations. For a recent example, see http://astronomia.udea.edu.co/
chelyabinsk-meteoroid/

I'll mention that the shell is irrelevant for the students, except of
course for print outputs and error messages. The students are writing full
programs in the edit window (with preferences set to bring up an edit
window, not a shell window).

Another significant feature of Polo's work that still hasn't made it into
IDLE is the preference option to permit not having to save the program at
all, something that makes a surprisingly big difference for
experimentation. Programmers who like playing experimenting in the shell
have the luxury of just typing and running, but programmers who like
writing short full programs in the edit window and hitting F5 to run are
inconveniently interrupted by the current IDLE in being required to save
the program somewhere, which interrupts the train of thought. Polo added a
preference to IDLE to permit running without ever saving the program (with
of course a warning if you kill the editor without saving).

Because I considered these improvements and various bug fixes carried out
by Polo to be so important, yet there seemed to be no way to get IDLE
updated, starting in 2009 I reluctantly have included his work under the
name of VIDLE (VPython version of IDLE) within the VPython installers.

Stepping up a level, it's preaching to the choir in this forum, but
removing IDLE (with or without improvements) is a terrible idea. Expert
programmers could care less, because they'll use Eclipse or Emacs or even
vi. It's really really important that upon installing Python you can start
work immediately with a good colorizing editor, even if you're a complete
novice.

Bruce

P.S. A couple of related news items: Assisted by Steve Spicklemire, I've
made a major change in the architecture of VPython so that it is now based
on wxPython, the cross-platform GUI library. This has made it possible to
eliminate almost all of the old platform-dependent code, which was written
in C++, and replace it with pure Python code. Among many other advantages,
this makes it possible for VPython to run on 64-bit Mac Python, where
VPython must necessarily be based on Cocoa, whereas VPython had been based
on Carbon. Unfortunately the Python 3.x version of wxPython ("Phoenix")
isn't quite ready for prime time, so the new version of VPython is
currently available only for Python 2.7.

Also, inspired by the easy-to-use VPython API, which has made it feasible
for programming novices to write Python programs that generate real-time
navigable 3D animations, with David Scherer I created GlowScript (
glowscript.org) which runs in a browser using WebGL, with programs written
in JavaScript or CoffeeScript. There's a Python program that helps convert
a VPython program to a GlowScript program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20130322/d3c36d10/attachment-0001.html>