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
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
2008/12/13 michel paul <mpaul213@gmail.com>:
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.
Does your shell let you get back to the top? In IDLE, once I'm down at the bottom, I have no easy way to drag the canvas upwards. I want to make the bottom >>> (prompt) go way up high, where the back row can see it better. Here's a screen shot: http://www.flickr.com/photos/17157315@N00/3105501071/sizes/o/ Kirby
kirby urner 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).
I'm creating the editor / cmd-shell on the flight, just as I want it at that moment. Integrating notes and code, as michel suggested is standard in my case, I want to want step further, integrating instructions, help and web, in the form of doc, xls, ppt, pdf, chm etc is very useful. Here is an example of the simple editor + "super cmd-shell" + vpython (sorry it's rather long, 10 minutes, 20 MB) http://mientki.ruhosting.nl/movies/vp1.html cheers, Stef
Having watched the 20M video and enjoyed it (especially the ER part -- work in hospitals) I'm thinking this could roll in to my Python for Teachers in March in Chicago. I've always wanted to see VPython treated that way, as one more panel in a set of panels. Kirby
I'm creating the editor / cmd-shell on the flight, just as I want it at that moment. Integrating notes and code, as michel suggested is standard in my case, I want to want step further, integrating instructions, help and web, in the form of doc, xls, ppt, pdf, chm etc is very useful. Here is an example of the simple editor + "super cmd-shell" + vpython (sorry it's rather long, 10 minutes, 20 MB)
http://mientki.ruhosting.nl/movies/vp1.html
cheers, Stef
participants (3)
-
kirby urner -
michel paul -
Stef Mientki