Wandering Thoughts archives

What do variable names mean (in Python and elsewhere)?

What are variables?

In many languages, variables are just labels for storage locations, for a spot in memory. This ranges from pure machine level storage, in languages like assembler, up through storage locations augmented with size and type information, such as in C, all the way to Perl, where the 'storage locations' are actually fairly abstract. But they're still there, even in Perl, partly because it's a comforting way to think about it: variables are where you put things.

In Python and some other languages, variables are bindings; they are references to something (often the somethings gets called 'objects', which can result in confusion with the sort of objects that are instances of classes). The objects have a life independent of the variables, and multiple variables can be bound to the same object, and you can have objects that aren't 'in' any variables at all.

In the storage model, you make copies of things all the time: 'a = b' puts a copy of the contents of b's storage location into a's storage location (possibly scrunching b up a lot if it doesn't fit). In the binding model, copies are rare and always explicit; 'a = b' simply makes a have the same binding as b, so they both refer to the same object.

The binding model is a lot more abstract than the storage location model; since the storage model is how computers work, it's often easier for people to wrap their minds around. It's also harder to clearly see the binding model, because the two models look the same as long as you're only dealing with immutable objects. (It may save you memory, but that's not something that most people notice.)

(You can even confuse the two models when you're programming in a binding language and write code that assumes the storage model when it's getting the binding model; this causes peculiar bugs.)

Capable storage model languages almost always grow explicit bindings of some sort, whether they call them pointers (C) or references (Perl). Once you've got explicit bindings, you can of course implement a binding language, because all a binding language really is is a language where all variables are actually pointers to otherwise anonymous blobs. (At this point you really want some sort of automatic garbage collection.)

Only languages with storage models have 'pass by value' versus 'pass by reference' issues with subroutine calls. When you have a binding language all subroutine calls should implicitly be pass by reference, since that's what passing a binding around is. (You can create a perverse binding language where subroutine calls make a copy of the objects the arguments point to and then pass in bindings to the copies. But you can make all sorts of perverse languages.)

Python is a 'context-free' binding language, where a variable's binding does not depend on its context. There are binding languages where this is not the case, so for example foo is one thing when taken as a function and another thing when taken as a variable; I believe Common Lisp is one big example. I personally prefer the Python way, because it's simpler, more regular, and easier to understand.

(For one technical discussion of the Lisp issues, see here.)

There are probably hybrid storage/binding languages out there. I think the easiest sort to construct is a statically typed language where 'primitive' types use a storage model and everything else uses a binding model. (To some extent this happens under the hood in most high performance binding language implementations.)

(Trivia: this entry is the 'another blog entry' from my comment on this entry. Sometimes my entry-writing mills grind very, very slowly.)

Sidebar: explanations of Python's object model

If you want to read explanations of Python's object model itself, try Python Objects, How to think like a Pythonista, or this discussion.