[Edu-sig] What is the Best Way to use Python in the Windows Command Line

2008-12-13 Thread csev
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

2008-12-13 Thread Igor Támara
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

2008-12-13 Thread kirby urner
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

2008-12-13 Thread Scott David Daniels

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

2008-12-13 Thread Stef Mientki

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

2008-12-13 Thread michel paul
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

2008-12-13 Thread michel paul
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