[Edu-sig] My experience teaching Python

[Martijn Faassen]

Michael Miller wrote:
[describes intro computer science class]
> We will make these changes in the next offering of this class:
> 
> - some how-to handouts on using IDLE
> - a book in addition to Learning Python; along the lines of "Thinking
> Like a Computer Scientist" or "Simple Program Design."

I'll take this as an opportunity to discuss my own limited experience
with teaching Python to new programmers.

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'll describe how I explained things to my friend (her 12 year old daughter
was also present during some sessions). Note that she only just got started
and therefore I can't promise this approach will work. I'll get a chance to
teach a number of other people starting next month, however, so I'll gather
more data then.

I described interactive mode first. Since my friend is moderately familiar
with command line environments this did not present too much of a problem
with her. I described the basic idea of some various types; strings and
integers, floats and longs. I didn't expect her to remember it all right
away, but at least it'd give her an idea of what's possible. I also
briefly mentioned lists.

I also introduced variables and assignments in the interactive mode. I paid 
special attention to the fact that you can basically use any word
(or number of words) as a variable. I also described some built in
functions such as int(), string() and float(). They are always there and
aren't too difficult to explain, so that was useful.

As I'm not much of an interactive mode user myself (though certainly it's
handy at times), I moved on to describe the editing environment. In my
case it was Emacs, which can be horrendously complicated. The basics are
pretty simple tough, and the python-mode is very nice (syntax highlighting
and easy way to run the code in the editor to see immediate results). The
menus under X helped a lot too. 

I showed how you can print stuff, such as the result of expressions.
After that, I introduced boolean expressions (perhaps I should've done
so already in the interactive mode). Then I moved on to 'if' statements, and
block based indentation.  All that was still pretty clear.

'for' loops presented more problems, though! I had quite a bit of difficulty
to explain that the for block gets executed for each element in the sequence,
and that the variable (for variable in foolist) refers to something else
each time in the execution. I need to think on a better way to express
things apparently-tricky thing.

I explained how to write a program that adds all numbers from 1 to 9 (or
any sequence of numbers, really), using the 'for' loop, and range(). This
was also pretty difficult to get across. The concept of an extra variable 'sum' 
that keeps the current sum while doing a loop is not something people hit
on by themselves!

After that I had them change the function to multiply instead of doing
additions (so you'd do factorials). Due to my explanation that you can
use basically any word for a variable, and also focusing on the idea that
you should use descriptive variables, my friend and her daughter automatically
started to change variables like 'sum' to 'product', and not only changed
the + to *. This was a rather nice thing to see, though I hope it wasn't
because they taught the computer actually understands what they call
these variables (I don't think they did think that though). Also tricky was
to change the starting value of '0' to '1' (otherwise the result is '0'), but
they both could figure this out for themselves.

I then turned the factorial program they had produced into a function.
In retrospect, I think I should've used the 'sum' program instead to 
produce a summing function, as it's probably conceptually easier to talk
about. Like in my explanation of the 'why' of looping (you don't want to
type 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9), I paid attention to the 'laziness'
issue: good programmers are lazy (in the right way), and don't want to
do boring stuff like lots of typing, and they definitely don't want to
do the same thing twice. This seemed to work well.

Still, I had some problems in making clear the concept of functions. I
started too difficultly by using the 'factorial' approach; I fell back
to a very simple function soon enough:

def simple():
   pass

I explained the difference between side effect and return value:

# return value
def simple1(a):
   return a

# side effect
def simple2(a):
   print a

# both
def simple3(a):
   print a
   return a

This turned out to be fairly tricky at first. The difference between
things like:

print simple1("hoi") 

and

simple2("hoi")

was not immediately clear. It got especially tricky when we saw:

print simple2("hoi")

The idea that Python returns 'None' when there is no return statement
came as a confusing surprise; I should probably have introduced 'None'
more early, but it's hard to motivate the existence of 'None' to a newbie,
which is an argument against discussing None too early.

The problem with the approach with 'simple' versus that of 'factorial' is
that 'simple' does demonstrate the mechanism of functions, but not the
*why* of it. 'factorial' is much more useful here. I still need to figure
out the right way to introduce the motivation for functions along with the
mechanism for functions without causing confusion on either.

What was useful (again in the lazy programming context) was the concept of
'recipe'. A function does not get executed just by it being there; it is
a recipe which you give to the computer. If you (daughter) give your
mother a cookie recipe that doesn't mean immediately your mom will go
and bake the cookies; you need to ask her to do so first. Unlike a mom,
a computer will always obey (as long as the recipe is right), unfortunately,
a computer is also very stupid so you have to be more detailed. :)

This analogy seemed to work pretty well.

That's about as far as I got this time. As you see you can spend lots of
time with the basics. This is not because the mechanisms of the basics
are generally hard to understand; they picked those up pretty well in 
general, though there were some problems. The problem is more one of
*why* these mechanisms are useful. What you can do with them, and how
you use them to do useful things. That's the real art of programming
(along with the importance of a well readable and maintainable program
structure).

I hope my observations were of any use to you all; I'll post more once I
have some more experience.

And-I-didn't-even-*talk*-about-case-sensitivity-to-them-yet-ly yours,

Martijn