[Edu-sig] My experience teaching Python

[Kirby Urner]

>I've taken a look at Learning Python and it doesn't seem to have the right
>structure if you're completely new to programming. My friend bought it 
>and hasn't been too much use to her so far, though I expect it probably
>will be later on.

I like your approach Michael.  Play in the interactive mode, show how
this can be used to test your understanding of the various operators
(sometimes I call them "toys" -- not in a deprecatory sense at all),
then go right into combining statements into function defs (programs).

This is a great segue from Logo (which many kids learn), which likewise
has the interactive command line, plus the short, atomic procedures.

A few comments:  

*  Those who can use IDLE will probably find it a lot easier than Emacs.  
   The newest IDLE even prompts for correct syntax, plus the stepwise 
   debugger (still rudimentary) gives beginners a fun way to watch simple 
   programs in action.

*  You can do a lot in interactive mode.  I like to show students that
   it's more fun to calculate at the command line than on a TI.  In 
   part because calculators don't have any savvy about alpha operations,
   like 3*"CAT" = "CATCATCAT".  Yet modern mathematics is a lot about
   symbolic manipulation beyond what we do with numbers.

*  Keep in mind that you, as a teacher, can pre-write simple modules 
   which, when loaded, do interesting things at the command line.  
   Then invite students to look at your code.  As another poster here
   mentioned, one way to learn programming is by learning to read 
   programs.  Like with any language, it's sometimes easier to scan
   stuff that's already "grammatically correct" (using your "recognition
   vocabulary") than to construct complete sentences yourself (which 
   requires "recall" -- more challenging than "recog").

If you haven't taken a peak, I invite you to check out my 3 part essay 
integrating learning Python within in a math class context.  The first 
section has really simple function defs, which then build in complexity 
(and move to object oriented) in the later pages:

   http://www.inetarena.com/~pdx4d/ocn/numerarcy0.html
   http://www.inetarena.com/~pdx4d/ocn/numerarcy1.html
   http://www.inetarena.com/~pdx4d/ocn/numerarcy2.html

... a fourth page is in the works.

My approach dovetails with yours, in that I'm focussing on the 
interactive command line at the start.  What's not explicit in these
pages is a lot of nuts and bolts about "types" (int, float, string),
which you get into, nor even data structures (list, tuple, dictionary).

This isn't because I'd want to skip any of this.  But first I want
to get students to "buy in" by seeing Python do a lot of relevant
work.  Then we start dissecting the code, and phasing in the nuts 
and bolts stuff using a more "and by the way" approach.  Start by
showing relevance, then get into the guts of programming.

I also like to stress that there's no "one right way" to implement
an algorithm (although, yes, some are more efficient).  That's
why I take pains to show recursive _and_ non-recursive ways of 
doing the same thing (factorial, for example).  Sometimes what 
you gain through recursion you trade away in decipherability.  
Other times, recursion is pretty elegant, and we hope students 
will appreciate this (especially if some of them are going to be 
CS majors someday, in which case we'll be turning them on to Scheme).

Kirby