[Edu-sig] what is a "variable" in Python?

kirby urner kirby.urner at gmail.com
Mon Feb 15 14:02:59 EST 2016


What do educators think about this discussion of variables in Python?

http://www.python-course.eu/variables.php

I find the "variable versus identifier" discussion, with repeated
references to C / C++, to be somewhat on the confusing side.

My view is "variable as container" makes sense if you're talking about the
object itself, on the heap, e.g. the list, dict or tuple or whatever.

I might write the word "Object" with a big "O" and say that represents "a
container in memory" (contains data and methods e.g. datetime.datetime
objects).

But then I'd say said object is "variable" only if it's mutable i.e. it
could be a constant (immutable) in contrast.  Strings and integers are not
"variables" as you can't do anything to mutate them.  Lists are variables,
strings are not.

Names, on the other hand, are like postits or luggage tags, more like
labels for objects, and we can pull a postit (like X) from an object (like
'A') and stick it on another object (say 3) instead.

This is *not* a matter of a variable changing i.e.

X = 'A'
X = 3

has nothing to do with "changing the content of a container" (as if 3 had
to fit into the same piece of memory as the 'A' did) but is rather about
slapping the name 'X' onto two different objects in quick succession.
Identifiers don't care what they stick to, as long as they're objects.

Objects always have type.

Names are just names:  they name things with type, i.e. objects.

It's not that mysterious -- but the "container" metaphor gets in the way
when you go:

>>> A = [1,2,3]
>>> B = A
>>> B[-1]=4
>>> A[2]
4

and then maybe think A should be pictured as a container with [1,2,3]
inside it.  So does B have [1,2,3] inside it too, meaning it's own copy?
Of course not, but two "containers" cannot logically "contain" the same
object which is why there's cognitive stress.  The "container" metaphor is
obstructive.

B and A are simply two postits, two tags, affixed to the same object, the
list on the heap, no big deal.

You can call that object a "variable" if you like, but why not just call it
a "mutable object" instead?

On the other hand, A and B are just names in the namespace.  We use them to
talk to / remotely control said objects, not just name them.  Names don't
have type and we don't name names, we name objects.

A name is a lot like a TV remote, with lots of buttons (dot notation
activated, lots of little callables).  An object is a lot like the TV.

More than one remote controlling the same TV is OK in Python.

There is no "container" in this picture unless you want to say the TV is a
container (an object), in which case I'd agree.  Saying the remote
"contains" the TV is not helpful and just gets in the way the second you
have two remotes for the same object.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/87c7ca7d/attachment.html>


More information about the Edu-sig mailing list