[Edu-sig] more on "variable names"

kirby urner kirby.urner at gmail.com
Sun May 24 04:43:22 CEST 2009

I filed the following quick comment after viewing a six minute
tutorial on variables and values at ShowMeDo.

The video:


My comment:
idea that values are "stored into" a variable is less the metaphor in
Python, which is more about assigning or binding names to objects with
the assignment operator (=).  The problem with "store into" is then
its hard to picture many names for the same object, yet that's easy
when you think of a balloon with many strings.

Yikes it posted three times dammit, makes me the foolish dweeb.

Anyway, based on our longish threads here awhile back, I think "we who
consider ourselves Python teachers" should actively check ourselves
against using the verbs "to store in" or "store into" with respect to
objects and their top-level names.

The reason is, once you picture a dog in a doghouse, with the variable
name as the doghouse, then it's hard to visualize how other doghouses
could contain the same dog (the same value) without there being
multiple copies of the same dog (clones?).

A better image is balloons on strings.  I realize it's not customary
to have one helium balloon with two or more strings, different hands
holding each string, sharing the same balloon, but there's nothing
conceptually difficult about it (feels kind of ubuntu), whereas with
that dog in the doghouse... that way madness lies.

As several teaching professionals were noting on this list, a Python
name is a lot more like a C pointer in the sense that it neither grows
nor shrinks with respect to that which it names, i.e. the "size of
object" is not a name's concern (another way to break the hold of the
container-contained imagery).

I think when we teach low level (including but not limited to
children), we actually mess with (rewire) basic associations, a common
technique in pedagogy (called "mnemonics").

For example, the so-called "equal sign" (=) would be better called an
"assignment operator" as most of us here do.

To make this link stick we could explain how the two parallel lines
represent "opening a channel to" i.e. now this name (on the left) will
be able to communicate with the object on the right (some result of

Why "open a channel to"?  Because now we have "dot notation" i.e. our
little API "control panel" at the near end of the string, our little
"interface words" (triggers, attributes, methods with args)... our
"messages" (to use Smalltalky talk).

We don't really want s = 3 to be read "s equals 3" in Python.

It's closer to "s names 3" or "s represents 3" or even "s speaks for 3".

Not "s stores 3", nor "s contains 3".

Probably the idea of "garbage collection" should be introduced right
at this juncture, with arched eyebrows ala Spock if we forget to
mention it.  That's a really good way to anchor the many-to-one
strings-to-balloon metaphor, with the idea of a reference counter on
the object.

Dogs in doghouses don't have reference counters, plus we wouldn't want
them garbage collected.

Balloons, on the other hand, go pop, which'd be a convenient way to
represent "freeing up memory".


PS:  do Python's where Prada?

More information about the Edu-sig mailing list