[Edu-sig] What is the Best Way to use Python in the Windows Command Line
I teach a number of classes at the University of Michigan that are about Python and that use Python.We have gone from no Python classes last year to five classes and four teachers that teach Python at UM. We share intro documentation on how to install and set up the environment. One thing that really bugs me is that the WIndows Python installer does not add itself to the Path automatically. Since I insist that students can be allowed to use Mac's or PCs - I try to create a similar environment for both and the command line is the lowest common denominator. I end up publishing detailed documents and screen casts to get python into your Windows path. It works but it is not where I want students energy focused in the first week of class. I am wondering if there is another way. I generally do not like IDLE - it uses a socket which can get messed up, bugs in the student's code seem to mess up the IDE, when a program needs to open a data file - it is hard to force IDLE into a known directory. Is there a way to use an icon and then start the icon an have the current working directory (i.e. to open data files) be the same directory as the Python file? And then is there a way to get the output to stop at the end and not disappear when the program finishes? I do not like solutions which include adding code to the student programs to do things like pause before terminating or setting the current working directory. The students have enough trouble figuring out the 20 lines of code that matter let alone 5-6 lines of obtuse code to set up the environment. I can continue to teach them how to set the PATH variable in Windows - if anyone on this list has a suggestion - I would much appreciate it. Thanks. Charles Severance University of Michigan ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] What is the Best Way to use Python in the Windows Command Line
Hi, maybe for the first weeks use crunchy, install a server somewhere, so they can use it, when you go further on the semester you can get them involved in the cli. Is a shame that advanced tools on the cli are hidden for people from GUI ones. Their minds will be expanded when they start to use the cli. Another way is to allow a machine with ssh for your students, so they are able to use say ajaxterm or something like that to start coding, they will be involved in having an account on a remote machine that holds they work. It turns interesting for people that are only used to just a PC(or MAC), without knowing the power of remote connections and the concept to **share** resources(machines and materials) and publish(public_html) their work. Well, if it's possible to setup a revision control system, on more courses, they will start to appreciate powerful tools, maybe the most advanced would be able to get in touch with many interesting things. My high school students started to use subversion and they got really involved and motivated when they saw graphics that showed their commits :) http://www.gfc.edu.co/repositorio/2008/ They have just finished their work now, but you can see a show of the work done of one of them on http://www.gfc.edu.co/~danmar/ He used visual python, pygame, curses and had a lot of fun coding... Finally, an option would be to have a linux(livecd) where the cli is really friendly where they have all the necessary packages without the hazzle of administering viruses and unpredictable results... P.D:We use Debian Linux at our school, and administration is really painless. Some of the students know how to install it, and have it also at their homes. This is a ongoing work that will reach its 10th aniversary ;) They start to use linux from 6 years old... csev I teach a number of classes at the University of Michigan that are csev about Python and that use Python.We have gone from no Python csev classes last year to five classes and four teachers that teach Python csev at UM. We share intro documentation on how to install and set up the csev environment. csev csev One thing that really bugs me is that the WIndows Python installer csev does not add itself to the Path automatically. csev csev Since I insist that students can be allowed to use Mac's or PCs - I csev try to create a similar environment for both and the command line is csev the lowest common denominator. csev csev I end up publishing detailed documents and screen casts to get python csev into your Windows path. It works but it is not where I want students csev energy focused in the first week of class. csev csev I am wondering if there is another way. csev csev I generally do not like IDLE - it uses a socket which can get messed csev up, bugs in the student's code seem to mess up the IDE, when a program csev needs to open a data file - it is hard to force IDLE into a known csev directory. csev csev Is there a way to use an icon and then start the icon an have the csev current working directory (i.e. to open data files) be the same csev directory as the Python file? And then is there a way to get the csev output to stop at the end and not disappear when the program finishes? csev csev I do not like solutions which include adding code to the student csev programs to do things like pause before terminating or setting the csev current working directory. The students have enough trouble figuring csev out the 20 lines of code that matter let alone 5-6 lines of obtuse csev code to set up the environment. csev csev I can continue to teach them how to set the PATH variable in Windows - csev if anyone on this list has a suggestion - I would much appreciate it. csev csev Thanks. csev csev Charles Severance csev University of Michigan csev ___ csev Edu-sig mailing list csev Edu-sig@python.org csev http://mail.python.org/mailman/listinfo/edu-sig -- Recomiendo Inkscape para hacer gráficos vectoriales http://www.inkscape.org signature.asc Description: Digital signature ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] Thoughts about IDLE
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
Re: [Edu-sig] What is the Best Way to use Python in the Windows Command Line
csev wrote: ...We share intro documentation on how to install and set up ... I end up publishing detailed documents and screen casts to get python into your Windows path. It works but it is not where I want students energy focused in the first week of class. I am wondering if there is another way. Have you considered contacting ActiveState? Their installers generally work very nicely for me, and I like to recommend them to people who want a turn-key install. I suspect you could talk them into some special deal to redistribute the installer as an academic institution, but at the very least your students could download their installer themselves for the economical price of $0.00. --Scott David Daniels scott.dani...@acm.org ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] What is the Best Way to use Python in the Windows Command Line
Massimo Di Pierro wrote: I do not know if this is helpful but the web2py windows distribution includes portable python and does not require installation. You just type web2py.exe -S admin and you have a python shell or you can do web2py.exe -S admin -R /path/to/yourfile.py It includes Tk all standard python libraries. There are have some bonus features that students may find convenient like browser based editor with syntax highlighting, wysiwyg editor for HTML files and easy to use database API. What do you use as the browser based editor with syntax highlighting and the wysiwyg editor for HTML files ? thanks, Stef Massimo ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Thoughts about IDLE
On Sat, Dec 13, 2008 at 9:09 AM, kirby urner kirby.ur...@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.ur...@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
[Edu-sig] synthetic division
On Friday we were studying synthetic substitution/division in Algebra 2. After going through the algorithm and after showing through factoring why it worked, I had them look at this code: def evaluate(polynomial, x): value = 0 for coefficient in polynomial: value = value*x + coefficient return value *polynomial *is a list of coefficients. This algorithm is identical to the factoring analysis I showed them. To then create the function 'divide' is a simple matter of returning a list of coefficients rather than one final value. This 'concept map' shows exactly the same thing as the diagram in our text, but it would be even more accurate to initialize *value* as polynomial[0] and to then make the for-loop 'for coefficient in polynomial[1:]', but I thought that in an environment where programming in math classes is still considered something alien, the indexing might cause some silly grade-anxiety reactions. How sad that this has to be an issue. But I figure that for the kids that are interested, and there are some, looking at indexing and splicing might be enticing. This has been my experience - looking at math concepts I have long taken for granted and thinking about how to express them in computational form as interacting functions/classes has shed new light on my own understanding. I can't help think that this would be invaluable for education. - Michel ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig