[Edu-sig] Thoughts about IDLE

[kirby urner]

Per very early in the edu-sig archive, I've always found IDLE both
necessary and sufficient for most of my teaching needs, whereas in
development I've used Vim (which I suck at), random editors and tools,
less Eclipse than you might think, Wing.  However, for quick scripts,
IDLE works on the job as well, especially in Akbar font.

What frustrates me in class though, is I'll get low on the projected
screen, having entered a bunch of session variables, identified a lot
of stuff, and then I'm sort of stuck to the lower edge, unable to wipe
to the top and/or mouse blank command line to the top (drag
operation).

What's great about IDLE over say IPython is how mouse friendly it is,
so easy to dive-bomb into a function def 100 lines back in time and
bring it down (into the present), for revisions.  You'll understand
why I'm so comfortable with this approach if you understand my
heritage as a dBase programmer.

I think some newcomers to snake charming might be surprised how many
of us came up through the pre open source ranks using xBase, which at
one time Microsoft touted as the third of three pillars, VB and C/C++
the other two.  Those were the bad old days before Unix swept the
world by storm in the form of GNU Linux and we got access to true
agiles.  But not everything about those days was a waste of time.  We
couldn't have gotten "here" without some kind of "there" there.

I think the future of IDLE (if I may speculate idly) will involve
getting those plug-ins for non Latin-1 keyboards to drive iconic
glyph-making on screen.

As to Python itself, I've been wondering allowed whether __op__ =
[klingon symbol] would be too terrible, or some other mechanism for
opening the operator overloading mechanism to arbitrary Unicode
symbols, without proliferating the number of special names in some out
of control fashion (i.e. you don't want a __[symbol]__ for each
possible symbol we might be tempted to repurpose).

Perhaps the more attractive option, consistent with my disdain for
"open oh" in place of __mul__, would be to restrict to these few
operators, and suggest developers disabuse themselves of the notion
that "more is better" in the case of operators to overload.  Not only
do you not *need* more than but a few (given how generic their
capabilities -- as Guido just pointed out, you can pervert / to
implement * if you care to, or just go __mul__ = __div__) but you
should curb your *want* for that many.  Think of your readers for a
change.

I'd be interested in what other teachers are doing when it comes to
projecting Python in front of the class and rattling stuff out in a
shell (not just showing scaffolding).  When we get low on the screen,
kids in the back have a harder time seeing.  Yet we want that
dBase-style chronology (characteristic of most shells, bash included)
and mouse friendliness, something more like a canvas, less like a
teletype.

Finally, as someone with bookkeeping heritage, I like shells which
"preserve mistakes" in the sense of keeping transactions on file,
almost like patches and diffs in a version control system.  You don't
want to be able to "change the past in the past" once you've got a
time sequence going, as that's not reflective of real time experience,
so breaks the metaphor.  If you had a typo at 2:30 PM, just copy it
down to 3:00 PM and edit it, don't pretend you got it right the first
time.  IDLE is like that.

Kirby