[Python-Dev] IDLE in the stdlib

[Kurt B. Kaiser]

On Wed, Mar 20, 2013, at 09:17 PM, Terry Reedy wrote:
> On 3/20/2013 6:48 PM, Kurt B. Kaiser wrote:
>
> Well, one can hardly use Command Prompt captures, unless one were to
> flip black and white within the window (but not its frame).

And yet many books do - it's really ugly.  When I see a book with a
bunch of DOS windows, white on black, printed on cheap paper, 900 pages,
I just put it back on the shelf.  Quickly.


> > I've always felt that IDLE should be targeted to an eight year old
> > beginner, and should work uniformly across the major platforms. That
> > now includes the Raspberry Pi!!
>
> I think it should also work uniformly across Python versions. That is
> the gist of PEP434.

Well, spending a lot of time backporting new features is not my idea of
fun. OTOH, I have no objection.  Maybe we could automate checkpoints of
IDLE into PyPI or somewhere for those who don't care to pull from hg,
yet want to be on the cutting  edge?

Along those lines, I've thought that IDLE should refrain from using the
newest features in Python, to allow people running released versions of
Python to access the newest IDLE.  i.e. Python 3.4 innovations would not
be used in IDLE 3.4.  Only Python 3.3 and earlier innovations.

[...]

> > OTOH, development is likely to be more vigorous if it's separate.
>
> Perhaps, perhaps not, or perhaps it would become 'too' vigorous if too
> many developers pushed multiple 'kitchen sinks'.

Oh, I agree with that.  Distributed version control can lead to chaos
and dilution of effort.

I don't know if this is the place to comment on PEP 434 (is it?), but
I've always taken the approach that IDLE development should be less
formal than the rest of stdlib, since it's not a dependency.  Big
changes should be reserved for the tip, but I don't see why something
like the right click menu change shouldn't be backported.

I think we should try a more relaxed idlelib development process inside
core before we move it out, and should be generous about adding checkin
permissions for that purpose.  Rietveld will help.  It's a good way to
habilitate new developers.

>
> > I'd also like to make a plea to keep IDLE's interface clean and
> > basic. There are lots of complex IDEs available for those who want
> > them.  It's natural for developers to add features, that's what they
> > do :-), but you don't hand a novice a Ferrari (or emacs) and expect
> > good results.  IMHO some of the feature patches on the tracker
> > should be rejected on that basis.
>
> Have you commented on those issues? I so far have mostly concentrated
> on fixing current features. I agree that major new features should be
> considered carefully and perhaps discussed on a revived idle-sig list.
> I have never used some of the existing features, like breakpoints,
> that seem pretty advanced. I first opened a debugger window only
> recently, in order to comment on a issue about a possible bug. We
> should document how to use that before adding anything else
> comparable.

I have commented over the years, but lately I've been so distracted by
the Treasurer job that I haven't found much time for IDLE.  And as I was
telling Ned here at PyCon, when you step off the train, it can be hard
to get back on.

I've tried to channel Guido over the years.  I looked at what he did,
and tried to project forward.

IDLE-dev is still active.  Would anyone else like to be a moderator?


> > It's sometimes said that IDLE is "ugly" or "broken".  These terms
> > are subjective!
>
> When IDLE-closing bugs are all fixed, I would like to see how much
> difference themed widgets would make to appearance. Then we could
> debate whether IDLE should look 'native' on each platform or have a
> common 'Python' theme -- or have both and let users choose.
>
> > If it's truly broken, then we should fix it.  If it's "broken"
> > because a feature is missing, maybe that's an intentional part of
> > Guido's design of a simple Python IDE.
>
> Without a vision and design document, it is sometimes hard for someone
> like me to know which is which.

IDLE development has always been organic, as opposed to the formal
approach of the PEPs.  What we need is a Zen of IDLE.  When I look at
it, I see a simple IDE.  I try to adhere to the principle of least
surprise, and to maintain an uncluttered interface suitable for
beginners.  Expert features can be there, but somewhat hidden (though
they should be documented!) or implemented as disabled extensions.

IDLE tries to promote Pythonic style.  For example, the lack of a
horizontal scroll bar was deliberate, I think.

We should implement the patch that adds an extension selector to the
options dialog, and keep the expert features as disabled extensions.

That way, an instructor could distribute an idlerc file which would set
IDLE up exactly as desired, including links to course specific help
files on the web.

BTW, I'll take this chance to promote the use of idlelib/NEWS.txt for
IDLE news, instead of Misc/NEWS.  That way, if IDLE is used outside of
the main release, the NEWS.txt will go with it.


Stability is paramount.

No surprises beats cool.

KISS is better than full featured.

Uniform trumps native look.

Experts go to the rear.

Where they can find what they want if they know where to look.

IDLE tests tkinter.

-- 
KBK