[Edu-sig] My experience teaching Python
Tue, 22 Feb 2000 10:50:44 -0800
>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:
... 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).