Variables vs names [was: Objects in Python]

[Steven D'Aprano]

On Thu, 23 Aug 2012 14:22:08 -0500, Evan Driscoll wrote:

> On 08/23/2012 12:56 PM, Steven D'Aprano wrote:
>> On Thu, 23 Aug 2012 12:17:03 -0500, Evan Driscoll wrote:
>> 
>>> I definitely *wouldn't* say "Python
>>> classes aren't really classes" -- even though (I assert) Python
>>> classes are *far* further from Simula-style (/Java/C++) classes than
>>> Python variables are from Java variables.
>> 
>> Well, Python classes are first-class (pun not intended) objects in
>> their own right, and hence are data. Java and C++ classes are not, they
>> are instructions to the compiler rather than data.
>> 
>> But other than that, what do you see as the difference between Python
>> classes and Simula-style classes?
> 
> So first, to some extent that's like saying "these two different things
> are different in this important way, but other than that, what's the
> difference?" :-)

Yes, exactly. I acknowledge a difference between the two, and ask you 
what differences you see.

Many languages do not have "first-class functions" -- you cannot pass a 
function to another function as an argument, or generate them on the fly 
at runtime. But the ability of functions to be treated as data is not an 
essential part of being-a-function, so I see no problem with describing 
both Pascal functions and Python functions as functions.

Likewise, being able to pass classes around as data and generate them on 
the fly is not an essential part of being-a-class, to I see no problem 
with describing both Java classes and Python classes as classes.


> But there are some other differences. (Not all of these are strictly
> with classes per se, but I would say they all have strong interactions
> with the object system.)

I don't believe that any of those differences in behaviour are either 
critical, or (as you acknowledge) strictly in the concept of *class* 
itself. I think they're interesting differences, but I don't think they 
are essential to the nature of "classness" in the same way that having a 
fixed memory address is essential to the nature of "memory location 
variable" or a name in a namespace is essential to "name binding 
variable".


[...]
>> Python has classes. They are created by the "class" keyword. Whether
>> those classes are identical to Java classes is irrelevant -- in Python,
>> these whatever-they-are-things are called "classes", and so Python has
>> classes.
>> 
>> But Python does not have things called "variables". There is no
>> "variable" keyword to create a variable.
> 
> OK, let's make a new language. I'll call it 'Python--' because at least
> *I* wouldn't want to program in it. :-)
> 
> In Python--, any time you use a name, you have to prefix it with the
> word 'variable':
>   variable x = 4
>   print(variable x)
> 
> Does Python-- have variables? 

Of course, because that's what Python-- calls them. Whether Python-- is 
*justified* in calling them variables is a more interesting question.

I think it is, in the sense that name bindings are a kind of variable, 
and fixed memory locations are a different kind of variable. But I also 
think that it isn't, for exactly the reasons why I prefer to describe 
Python (without the minuses) as having name bindings rather than 
variables "in the C or Pascal sense".

Ultimately what is important are the semantics of the words, not the 
words themselves. Objections to use of "variable" are, I believe, 
*pragmatic* objections that the word comes with too much baggage to be 
safe to use, not that name bindings aren't a type of variable.


> Think of it as duck-typing the term "variable". :-) To me, Python locals
> and globals look and quack like a variable.

And so they should, since name bindings are a way of implementing the 
abstract Variable kind, so to speak.


> Incidentally, I also realized another reason I don't like the 'names'
> description. Take 'foo.bar'. (That is, the 'bar' attribute in object
> 'foo'.) Is 'foo.bar' a name? 

Is "Evan Driscoll" a name? Or is it two names?

There is no contradiction to say that "Evan Driscoll" is both a name (a 
"compound name", if you like, or fully-qualified name) and two names (a 
personal name plus a family name).

foo.bar is both a fully-qualified name and two names: the name of the 
namespace and the name of the attribute in the namespace.


> I'm not sure what the 'names' proponents
> would say, but to me both answers are problematic. I *really* dislike a
> 'no' answer because to me, 'foo.bar' absolutely *is* a name for the
> corresponding object. (This terminology has precedent.) But a 'yes'
> answer, if you also reject 'variable', means you no longer have an
> agreed-upon term for the names that are defined in the current scope

"Local names".

We also have "global names" for those in the global scope, "builtin 
names" for those in the built-ins, and "nonlocal names".



-- 
Steven