[Idle-dev] Removing IDLE from the standard library

[Kurt B. Kaiser]

On Sun, Jul 11 2010, Bruce Sherwood wrote:

> On the notion that IDLE is fatally flawed and is driving away
> potential users of Python (to put the statements in their most extreme
> form):
>
> It seems that there are (at least) two very different communities
> people have in mind. I can appreciate that highly expert programmers
> may find IDLE insufficient for their needs, and it might even be the
> case that these people should be advised not to even try IDLE. But I
> want to stress as strongly as possible that for a very large community
> of nonexpert users of Python, IDLE has been extremely important and
> works very well for their purposes. Editing is pretty much like what
> they're already used to in word processors, which is certainly not the
> case with professional tools such as vim or Emacs.

Particularly on Windows, there is an expectation that a contemporary
programming language comes with a GUI.  Using the Windows Python shell
isn't very satisfactory, largely because of the poor file handling
capability in that environment.  IDLE provides a simple solution,
suitable for beginners as well as experts.  It provides one-keystroke
save/run in a fresh environment not associated with the GUI.  I have run
IDLE inside IDLE (though I'm not positive that will work right now).
How many IDEs can do that?

I've tried to channel Guido, and my general approach has been to provide
as much functionality as needed, but to hide the more advanced features
to avoid clutter.  When the 'experts' need them, they will find them.

I'm mystified about the comments that the GUI is ugly.  It is minimal.
On XP, it looks exactly like an XP window with a simple menubar.  Those
who haven't looked at it for awhile may not be aware of the recent
advances made by Tk in native look and feel.  What is ugly?

And IDLE is cross-platform.  There are perhaps deficiencies on the Mac,
but Ron has made good progress.  I haven't been able to come up with a
Mac yet, so I can't really comment.

IDLE works on 2.7 and 3.x.  Running IDLE on the trunk is a decent
test of Python and tkinter during development.

It seems that people who do Scheme write Scheme implementations, while
people who do Python write IDEs :-)

Usually, they keep adding features and buttons until it looks like
Eclipse.  That's fine.  But why turn IDLE into another example of that
style and diminish diversity in doing so?

On a netbook, screen space is at a premium, and a simple interface has
advantages.  There are many IDEs listed on the wiki if people are
looking for the more complex style, but I'd suggest that they aren't
appropriate for beginners.  And by beginners, I include elementary
school students.

IDLE works with "extensions".  Plug-ins, if you will.  The Option dialog
needs enhancement to support extension selection, and I believe there is
a patch to do that.  More extensions would be a good thing.

The .idlerc directory determines IDLE's configuration, including the
help source urls available on the Help menu.  By downloading .idlerc or
via indirection, a student environment can be set up including the day's
lesson and which extensions are activated.  Call tips and method name
completion can be "hidden" by increasing the time delay before they pop
up.

> That said, yes, there are some significant deficiencies with the
> current IDLE (which is why there's a VIDLE, for instance). I'm very
> glad to hear from Martin that Guilherme is free to commit his
> important bug fixes and improvements. I'm afraid that neither
> Guilherme nor I understood the procedures and thought that we had to
> wait for others to act.

Tal has made a couple of comments about not being able to run multiple
IDLEs at the same time, and he mentions

http://bugs.python.org/issue1529142

This bug has been closed for over a year, and you can run as many IDLEs
as you like.  You can run 2.7 and 3.x at the same time.  I would have
expected Tal to know that.

Also, the current right click edit action on Windows is to only open an
edit window; no shell.  And it uses the subprocess!  So, some of the
comments on this thread are not up to date.

The reason that bug languished for two years was because first, it was a
bit of a hack, and second, Windows was problematic in that it reused
sockets and often left zombie subprocesses behind which couldn't be
killed except with the task manager.  This causes real problems with
students - they lose confidence in the tool.

Scherer and Weeble put together a patch using ephemeral ports which
nailed the problem, and I checked it in right away and
forward/backported it.

As I recollect, much of what Scherer did in VIDLE related to running
multiple IDLE copies.

For that reason, the VIDLE changes have to be evaluated carefully to
determine what has already been incorporated.  I believe I added a
couple of his smaller changes, also.

Bruce, speaking of Dave Scherer, we've been trying to get a Python
Contributor Agreement from him.  Is that something you can help us with?

-- 
KBK