On Sat, Dec 13, 2008 at 9:09 AM, kirby urner <span dir="ltr"><<a href="mailto:kirby.urner@gmail.com">kirby.urner@gmail.com</a>></span> wrote:<br><br><div style="margin-left: 40px;">What frustrates me in class though, is I'll get low on the projected<br>
screen, having entered a bunch of session variables, identified a lot<br>
of stuff, and then I'm sort of stuck to the lower edge, unable to wipe<br>
to the top and/or mouse blank command line to the top (drag<br>
operation).<br><br></div>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. <br>
<br>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. <br>
<br>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.<br>
<br>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.<br><br>- Michel<br><br><div class="gmail_quote">On Sat, Dec 13, 2008 at 9:09 AM, kirby urner <span dir="ltr"><<a href="mailto:kirby.urner@gmail.com">kirby.urner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Per very early in the edu-sig archive, I've always found IDLE both<br>
necessary and sufficient for most of my teaching needs, whereas in<br>
development I've used Vim (which I suck at), random editors and tools,<br>
less Eclipse than you might think, Wing. However, for quick scripts,<br>
IDLE works on the job as well, especially in Akbar font.<br>
<br>
What frustrates me in class though, is I'll get low on the projected<br>
screen, having entered a bunch of session variables, identified a lot<br>
of stuff, and then I'm sort of stuck to the lower edge, unable to wipe<br>
to the top and/or mouse blank command line to the top (drag<br>
operation).<br>
<br>
What's great about IDLE over say IPython is how mouse friendly it is,<br>
so easy to dive-bomb into a function def 100 lines back in time and<br>
bring it down (into the present), for revisions. You'll understand<br>
why I'm so comfortable with this approach if you understand my<br>
heritage as a dBase programmer.<br>
<br>
I think some newcomers to snake charming might be surprised how many<br>
of us came up through the pre open source ranks using xBase, which at<br>
one time Microsoft touted as the third of three pillars, VB and C/C++<br>
the other two. Those were the bad old days before Unix swept the<br>
world by storm in the form of GNU Linux and we got access to true<br>
agiles. But not everything about those days was a waste of time. We<br>
couldn't have gotten "here" without some kind of "there" there.<br>
<br>
I think the future of IDLE (if I may speculate idly) will involve<br>
getting those plug-ins for non Latin-1 keyboards to drive iconic<br>
glyph-making on screen.<br>
<br>
As to Python itself, I've been wondering allowed whether __op__ =<br>
[klingon symbol] would be too terrible, or some other mechanism for<br>
opening the operator overloading mechanism to arbitrary Unicode<br>
symbols, without proliferating the number of special names in some out<br>
of control fashion (i.e. you don't want a __[symbol]__ for each<br>
possible symbol we might be tempted to repurpose).<br>
<br>
Perhaps the more attractive option, consistent with my disdain for<br>
"open oh" in place of __mul__, would be to restrict to these few<br>
operators, and suggest developers disabuse themselves of the notion<br>
that "more is better" in the case of operators to overload. Not only<br>
do you not *need* more than but a few (given how generic their<br>
capabilities -- as Guido just pointed out, you can pervert / to<br>
implement * if you care to, or just go __mul__ = __div__) but you<br>
should curb your *want* for that many. Think of your readers for a<br>
change.<br>
<br>
I'd be interested in what other teachers are doing when it comes to<br>
projecting Python in front of the class and rattling stuff out in a<br>
shell (not just showing scaffolding). When we get low on the screen,<br>
kids in the back have a harder time seeing. Yet we want that<br>
dBase-style chronology (characteristic of most shells, bash included)<br>
and mouse friendliness, something more like a canvas, less like a<br>
teletype.<br>
<br>
Finally, as someone with bookkeeping heritage, I like shells which<br>
"preserve mistakes" in the sense of keeping transactions on file,<br>
almost like patches and diffs in a version control system. You don't<br>
want to be able to "change the past in the past" once you've got a<br>
time sequence going, as that's not reflective of real time experience,<br>
so breaks the metaphor. If you had a typo at 2:30 PM, just copy it<br>
down to 3:00 PM and edit it, don't pretend you got it right the first<br>
time. IDLE is like that.<br>
<br>
Kirby<br>
_______________________________________________<br>
Edu-sig mailing list<br>
<a href="mailto:Edu-sig@python.org">Edu-sig@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/edu-sig" target="_blank">http://mail.python.org/mailman/listinfo/edu-sig</a><br>
</blockquote></div><br>