Variables vs names [was: Objects in Python]

[Evan Driscoll]

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?" :-)

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.)

* Explicit 'self'. OK, this sounds just like a minor syntactic
  difference, and in some respect it is. (For some time I considered it
  an annoying piece of syntactic salt.) But it has significant
  interactions with other things which you can do, such as using a
  method as just a normal function ('type(c).f(c)' ~= 'c.f()')
  or attaching other functions to an instance or a class (more on that
  later).

  This is definitely my weakest argument. :-)

* Fields. In Simula-style classes, you can tell easily what fields a
  class and its objects contain. In Python, that question from some
  point of view doesn't even make sense (in the absence of __slots__).
  Fields are a property of the *objects* rather than the class, and
  two objects of the same class don't necessarily have the same fields.

  Related to this point we have...

* What it means for an object to have a particular class type. With
  Simula-style classes, if I have an object 'o' of class 'c', then I
  know that 'o' has the functions and fields defined by 'c'. Now, the
  virtual functions may have been overriden in base classes and stuff,
  and maydbe they'll always fail, but I at least know they're *there*.

  In Python, I know... well, nothing basically. As far as I know, it's
  possible to make it so that o's only relation to 'c' is what
  'type(o)' and 'instanceof' say. (And maybe you can even override
  those, I dunno!) You can go through and add/remove/replace functions.
  Two different objects of the same class may have completely disjoint
  sets of attributes.



> Given:
> 
> x = some_object()
> y = x
> 
> I could say that x and y are the same object, rather than x and y are 
> references to the same object.

Huh, fair enough.


>> To me, saying "here's an alternative way to look at variables" is great,
>> but saying "Python doesn't have variables" is, IMO, at least as silly as
>> what Jussi said. To me, dancing around the issue just leads to more
>> confusing terminology and makes things worse.
>>
>> (And this is reinforced by the fact that neither I nor Google seems to
>> have really seen "Python doesn't have classes" ever used, when that
>> statement is at least as true as "Python doesn't have variables".)
> 
> I think you are utterly wrong here.
> 
> 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? Does Python? To me, the answer to those
questions basically has to be the same -- after all, the new 'variable'
keyword didn't really change the language, just have it a slightly
different concrete syntax. Heck, if I wanted to implement Python--, the
only thing I'd have to change in a Python implementation is the lexer!

And if you say "no, Python-- doesn't have variables, it just has
something that it wrongly calls variables", then it's no contradiction
to say "Python doesn't have classes, it just has something that it
wrongly calls classes."

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



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? 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 --
and such a term is a really good thing to have! (<cheeky>I know, let's
call them variables. :-)</cheeky>)

Evan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 545 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20120823/14b0a6ce/attachment.sig>