How to Teach Python "Variables"

[Chris Mellon]

On Nov 26, 2007 1:21 PM, davisn90210 at gmail.com <davisn90210 at gmail.com> wrote:
> Hrvoje Niksic wrote:
> > greg <greg at cosc.canterbury.ac.nz> writes:
> >
> > > none wrote:
> > >>     IIRC, I once saw an explanation how Python doesn't have
> > >> "variables" in the sense that, say, C does, and instead has bindings
> > >> from names to objects.
> > >
>
> IMHO, this is nonsense.  All that variables are (in any language) are
> "bindings" for names.  Pretending python does anything novel with
> regard to "variables" is confusing and, ultimately, simply results in
> a redefinition of terms programmers are already familiar with.  I
> mean, it's kind of like saying my computer is not a computer but is
> actually a device that follows input directions.  Of course that
> description may be true (and I may even use it to explain to students
> *what* a computer is), but it is no less a computer for it.
>

Long real-life experience that people with previous programming
experience, especially C programmers, have a great deal of trouble
with this concept. Python "variables" do not work the way they do in
other languages, where variables are compile-time bindings for memory
locations. Even Java references aren't the same (there's no such thing
as a null reference in Python, for example).

> > > If you're talking to C programmers, just tell them that Python
> > > variables always contain pointers. That should give them the right
> > > mental model to build on.
> >
> > That is a convenient shortcut when it works, but in my experience it
> > tends to confuse the issue.  The reason is that one of the main uses
> > of pointers in C is implementing pass-by-reference.  A C programmer
> > told that Python variables internally hold pointers expects this code:
> >
>
> I think most C programmers are smart enough to figure out the supposed
> differences, with only a little additional explanation on the part of
> the instructor.  Python's "variable model" is practically identical to
> that of Java, after all, and I don't recall any discussion of
> cataclysmic proportions over the differences between C "pointers" and
> Java "references".  There are "differences" (or more accurately
> "points of emphasis"), but of the sort that take a paragraph or two of
> explanation/clarification -- not a completely new model.
>

C programmers, when told that Python works like this almost *always*
get this wrong, because they want to pretend that Python is C-like
pass by reference and it isn't.

The very first thing they want to do is to get at "the pointer"
underneath the object so they can simulate C style pass by reference
with ints. It takes a lot of bandwidth (both mental and electronic)
before they get that there is no underlying pointer and they can't do
this.

The second thing they want to do is to intercept rebinding actions,
like you might do in C++ with operator overloads. If you explain it to
them in these terms, it is not clear (and will not be, until you use
other terms) that rebinding a name (assignment) and mutating an object
are fundamentally different operations.

I see these questions on a daily basis in #python and somewhat less
frequently in c.l.p. Your assertion that C programmers will "just get
it" if it's explained in those terms is simply not borne out by real
world results.

One thing that C programmers *do* get, at least the smarter ones, is
explaining it in terms of the actual implementation - that there are
PyObject structs that are not exposed, that they are refcounted, and
that name/object bindings are entries in various hash tables. Saying
"it's just like a pointer" isn't generally sufficient, because it's
not like a pointer, and it gives them totally the wrong model to work
with.


> > def func(a):
> >   a = 10
> > ...
> > func(x)
> >
> > to change the value of x.
>
> Depends on how you implement the C "equivalent".  The most direct
> translation, IMHO, is the following:
>
>   void func(int *a){
>     a = 10; //Of course this is nonsense, but it illustrates the
> point.  Just because "a" is a pointer
>                  //does not mean that "a" is not rebound when it is
> assigned to.  Oh wait!  Did I use
>                  //the word "rebound" when talking about a *C*
> variable? ;-)
>     //*a = 10; //I'm guessing this is what *you* had in mind, but it
> is very different
>   }
>

The very first thing a C programmer will want to do when seeing this
snippet is ask how to do the later operation in Python. If you tell
them they can't, they will then think of python variables as "like
pointers, except for special cases" which is wrong. If you use Python
semantics to explain it, in terms of names and bindings, they'll see
that it's not at all like pointers, that assignment operations are
totally consistent (assignment is name binding, not mutation) and that
immutable objects are immutable by virtue of not having mutating
methods, not because of compiler magic.

The only "special cases" which then need to be explained are augmented
assignment and object attribute assignment, which are easily (and
correctly) explained as being syntactic sugar for mutate + rebind and
a mutating method respectively.