Variables vs attributes

[Steven D'Aprano]

On Sat, 12 Sep 2009 00:39:17 -0700, Miles Kaufmann wrote:

> On Apr 17, 2009, at 8:56 PM, Steven D'Aprano wrote:
>> If an integer variable is an integer, and a string variable is a
>> string,
>> and float variable is a float, and a list variable is a list (there's a
>> pattern here), shouldn't a class variable be a class and an instance
>> variable be an instance?
>>
>> I had never noticed the usage of "variable" to mean attribute until a
>> few
>> months ago. What's going on? Why did people decide that confusing
>> variables and attributes of variables was a good thing? What's next,
>> describing dictionary keys as "dictionary variables"?
> 
> (Replying to this old message because I've seen you make this point in
> several threads recently)
> 
> Let me prefix this by saying: I don't like to use the word "variable"
> when being specific about Python, because its meaning isn't well
> established like "name" or "object".  Personally, I think most people
> use "variable" when they're thinking about Python in terms of C-style
> assignment semantics (which isn't accurate, but as a newbie you can get
> away with it for a little while), or when they're conflating a name with
> the object it refers to.  But I don't think there's a well- established
> definition in Python (because it implies a storage model that Python
> doesn't use), and it certainly isn't synonymous with "object".

Agreed, but you can make a fuzzy definition of "variable" as "object 
bound to a name" in some sense. It's imprecise when used to discuss 
Python, but not so imprecise as to be useless, and it has the advantage 
that it is easier to talk about "variables" than name binding semantics. 
Often the differences are unimportant, but beware that it can sometimes 
be misleading.



> As far as "class variable" and "instance variable" go:
> 
> They're used across many object-oriented languages:
> http://en.wikipedia.org/wiki/Class_variable

The Wikipedia article doesn't support that assertion. The only examples 
it gives are C++ and C#, and see the comments in the talk page. But 
perhaps you're right, and it is widespread across many OO languages -- if 
so that's another example of the pernicious influence the C family of 
languages have had on programming. Just because something is common 
doesn't make it sensible.


> The Python language reference uses that terminology:
> http://docs.python.org/reference/datamodel.html
> 
> As does Guido himself:
> http://people.csail.mit.edu/rudolph/Teaching/Lectures/guido-intro-2.pdf
> 
> We're blessed with a variety of object-oriented almost-synonyms to
> choose from, some of which are more Pythonic than others.  


It is difficult to avoid using the word "variable" when discussing 
Python. I've tried to use "name binding" and "object", and frequently it 
makes the discussion unnecessarily complicated while not communicating 
any additional meaning. (On the other hand, there are times when using 
"name binding" is absolutely essential and "variable" must be avoided.) 
Consequently, a little bit of sloppiness can be forgiven, if being 
technically correct gets in the way of communication.

But the same is not true for the terms "class/instance variable": there 
is never any reason to prefer them over the synonyms "attribute" (as 
commonly used in Python), "property" (as used in, say, Hypertalk), or 
even "member" (although member tends to be more general, in languages 
where methods and attributes are different types of things). At best, it 
is a pointless redefinition of "variable" in languages that don't have 
first-class classes (and therefore can't assign a class to a variable). 
At worst, in languages like Python that do have first-class classes, it 
is actively confusing.


> But I don't
> think it's worth "correcting" everyone who uses the phrase "class
> variable", especially when their use of it causes no confusion.

But it does cause confusion. Python has an exception AttributeError, not 
VariableError. Sloppiness can be forgiven when it makes no difference, 
but that's not the case here. When I read "class variable", I actively 
have to force myself to remember that the writer isn't talking about 
storing a class in a variable (that is, bind a class object to a name) in 
the same way that you would bind an int to a variable, but that they're 
talking about a class attribute.

This is Python, and we treat classes as first-class objects. I don't know 
what people do in other languages, but I often write code like this:


classes = [int, long, MyInt, SpecialInt, SomethingElse]
for cls in classes:
    do_something_with(cls)

We even do this:

class Parrot:
    # whatever
Parrot = class_decorator(Parrot)

(or use decorator syntax in Python 2.6 or better). This drives home the 
message that if class variable has any meaning in Python at all, it is of 
the names Parrot and cls.

The problem is even worse when people talk about "instance variables". In 
languages like ObjectPascal (Delphi) that require declarations, you need 
to declare a variable before you can use an instance:

type
  Shape = object
  end;

var:
  ashape = Shape;

You can talk about ashape being a Shape variable, but how do you discuss 
the process generically without reference to a specific type? The natural 
way is to talk about defining an instance variable, and that's what 
Delphi coders apparently do -- but C++/C# muddies the water by using 
"instance variable" to mean something radically different.



-- 
Steven