[Edu-sig] more on "variable names"
kirby.urner at gmail.com
Sun May 24 18:16:43 CEST 2009
On Sat, May 23, 2009 at 7:43 PM, kirby urner <kirby.urner at gmail.com> wrote:
> 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.
Someone took care of this, not sure why I'm anonymous as I used my
name -- probably because not logged in?
I added another comment supportive of his idea to make the model clear
using garbage collection:
> 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.
Someone pointed out off list that it *is* customary to have one helium
balloon with two or more strings. In parades!
You might use these in the classroom, in slides, in tutorials. Each
string-holder is a different variable name whereas the balloon itself
is the object. So when do we get a Python balloon? Could be virtual
I think it's fine to talk about "Python's economy" i.e. there's an
economy that is Python's, and includes memory management, the search
path, other environment variables (if you've set them). Python then
"paves the way" for these office buildings (many of them free) such as
Zope and Twisted -- just download and go to town, plant them in your
CBD (central business district) and put 'em to work (do some reading
first -- takes time to become a FOSS boss (like the mayor of a virtual
city, an economy)).
Python is economical in not adding to the number of memory-hog objects
gratuitously, simply as a result of assignment operations. For this
reason, we avoid "dog in a doghouse" or "thing in a box" type
metaphors when describing top-level naming. Even data structures such
as lists are best approached with string (versus containment)
Given a primary notion of "string" already in popular consciousness is
the URL (a handle), we can start thinking of objects as "servers" in
the background, with variable names more like "clients" (with a
channel open: client = server).
Or instead of a web service, there's maybe a remote control engine on
a track someplace, weighs a ton (literally) and several people have
monitors with APIs for controlling it or at least displaying its
location and status (moving?).
When you go mystring = yourstring, you don't want the suggestion of
cloning or copying something gigantic in memory -- you'd need to
import from a different module for that, maybe do a deepcopy (more
like a DVCS based approach).
I use 'Code Guardian' (a short downloadable movie -- also on Youtube)
to talk about controllable objects sometimes (these are big ones,
giant robots by someone who knows movies really well) -- but mostly to
talk about render time versus real time animation (this is render
time). I run a course for Saturday Academy focused on animation
concepts as this is ToonTown after all (we make lots of animations in
Portland, especially when you count in the commercials e.g. Nike,
(the source for the movie, others too)
(suppose the robots aren't AI, but Python puppets)...
Hey, big food fight on math-teach over whether to teach more SQL on a
digital math track alternative to the continuous math track (analog)
used by the calculus mountain people. I think I scored some points
for DM. Litvins is helping by the way (its mere existence, snake
cover not "too scary" -- reminds me of Prada).
DM vs CM (DM winning):
More information about the Edu-sig