[Edu-sig] Monkeys! (was turtles)

kirby urner kirby.urner at gmail.com
Sat Mar 4 03:45:24 CET 2006

So with my 8th graders this week, we were back to writing a class. 
Here's the eventual definition:

class Monkey:

    def __init__(self, name):
        self.name = name
        self.stomach = []

    def eat(self, food):
        print "Yum, thanks for the %s" % food

    def __repr__(self):
        return "Monkey named %s" % self.name

We didn't do this all at once, e.g. I had the
self.stomach.append(food) line before I'd mentioned a stomach
elsewhere and said this wouldn't work, because you couldn't append to
a list that didn't yet exist.  How to fix?  My most advanced student
raised his hand and gave the right answer:  start with an empty list,
and put it up top in the constructor.

In my patter, I make sure to say words like "instantiate" and "object"
a lot.  I talk about classes as "blueprints" (like for a house)
whereas what you actually "instantiate" from a blueprint, or plan, is
an object, an actual house with its own color.

Then each student created a bunch of Monkey objects, after saving the
above in site-packages as zoo.py.

>>> from zoo import Monkey
>>> m1 = Monkey('BoBo')
>>> m2 = Monkey('George')  # as in Curious George

At this point, I'd go around the room helping any student with broken
code.  Common errors:  saved as Zoo.py but importing from zoo.py. 
Missing colon somewhere.  Single under instead of underunder. 
Inconsistent indentation.  Of course I'd talked about all of these
possible mistakes in some detail, but kids sometimes tune out or are
involved in other things.

A couple tried to do all this in shell mode, instead of in a text
window (I have them Save As zoo.py immediately, even with a blank
slate, to get the color coding).

A couple thought where I wrote 'name' they should substitute an actual
name, like 'Andy' i.e. they were not yet clear on the difference
between variable-as-storage and value.

Actually, the first thing I did was put triple-quote comments up top,
and talk about conventions of indicating alpha, beta and
production-ready code.  Kind of an interlude, story time.

Anyway, back to the shell:

>>> m1.eat('banana')
Yum, thanks for the banana
>>> m1.eat('coconut')
Yum, thanks for the coconut
>>> m1.stomach
['banana', 'coconut']

I asked what would be in m2's stomach and a chorus of voices gave the
right answer:  nothing yet, because only m1 had been fed.

Then, as it was almost the end of the period, I had a brainstorm. 
Let's feed m2 to m1!

>>> m1.eat(m2)
Yum, thanks for the Monkey named George
>>> m1.stomach
['banana','coconut','Monkey named George']

Hah hah.  They thought that was pretty funny.

Then I had m2 eat itself.  OK that was just weird.  Kirby is just
Kirby I guess (yum).

Next week, we'll be writing a more generic Mammal class and having our
Monkey and Dog inherit from it.  We'll also get more deeply into the
Dictionary type (so far, I've only discussed lists, and strings in sum
detail, including string substitution syntax).

Once we have the dictionary type more understood, I'll be able to
mention self.__dict__ and talk about how the individual "state" (e.g.
the stomach) of each object (e.g. each Monkey) is saved in a

I like diving into OO pretty early, obviously.  I'm not one of these
"let's do procedural programming for a year and get around to OO only
in year number two."  No way Jose!


More information about the Edu-sig mailing list