[Edu-sig] Thoughts about IDLE

[michel paul]

On Sat, Dec 13, 2008 at 9:09 AM, kirby urner <kirby.urner at 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20081213/c0f1b406/attachment.htm>