On Sat, Dec 13, 2008 at 9:09 AM, kirby urner <kirby.urner@gmail.com> wrote:
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).
I have found it useful to resize the shell and a programming window so each occupies one half of the screen. Above in the programming window is text I want to present, and below is the Shell waiting for interaction.
I like the idea of intermingling text and executable code. Using triple quoted blocks, you can use a programming window like an extremely primitive text editor, and I appreciate the simplicity of that. I put down the thoughts I want to express as simple text, as in email, and I break up the text blocks with lines of code to illustrate what I'm trying to say. So instead of commenting being used to explain code, I use executable code to illustrate text.
I think it makes more sense to have the presentation text be the top window and have the Shell be the bottom window, but then you can get the same boxed-in thing happening at the bottom. But the half-windows can easily be dragged around. The arrangement isn't rigid. So if I need the Shell for extended interaction I can drag it to center or expand it, but if I want to go back to the primary material, it's easy.
That's what's so cool about pure and simple Python right out of the box. You can use it in all kinds of ways.
- Michel
On Sat, Dec 13, 2008 at 9:09 AM, kirby urner
<kirby.urner@gmail.com> wrote:
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
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig