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 -- http://mail.python.org/mailman/listinfo/python-list
