Objects in Python

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu Aug 23 13:56:25 EDT 2012


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?



> On 08/23/2012 03:59 AM, Jussi Piitulainen wrote:
>> I would also avoid any distinction between an object and a "reference"
>> to an object, except as an implementation detail. It's not helpful.
> 
> Whaaaa....?
> 
> How would you describe it then? To me, that distinction is absolutely
> *fundamental* to understanding how languages like Python/Scheme/Java
> work, because it tells you how to reason about aliasing behavior in an
> unconvoluted way (which is essential to understanding how they work).
> 
> How would *you* suggest dealing with that issue?

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.

Sometimes, when I say "x", I mean the *name* x, which is a reference to 
some object.

Much more often though, when I say "x", I use it as a convenient label 
for some object. Rather than saying "the object which is referenced to by 
the name x", I just say "x".

Nearly always, the meaning is obvious in context.


[...]
> *However*, this thread wasn't really prompted by someone just trying to
> explain variables in different terms -- it was prompted by one of the
> many comments you see from time-to-time that "Python doesn't have
> variables – not as C or Java programmers would understand the term".

No offence to Ben Finney, but I think sometimes he's a bit too eager to 
emphasise the subtle differences between Python and other languages, 
rather than the similarities. (I used to be like Ben in this regard, but 
I got better -- or worse, depending on your perspective.)

Again, context is important: sometimes I will choose to gloss over the 
differences by calling x a variable, and sometimes I will emphasise the 
differences to C or Pascal by referring to name binding.


> 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. It is absolutely fundamental to 
the programming model of Python that it has objects which are bound to 
names in namespaces (and other entities, such as list items). That is 
*critical* -- Python uses name bindings.

But name bindings are a kind of variable. Named memory locations are a 
*different* kind of variable. The behaviour of C variables and Python 
variables do not follow the Liskov Substitution Principle -- you can't 
rip out the entire "names bound to objects" machinery of Python and 
replace it with C-like named memory locations without changing the high-
level behaviour of Python. And so by some ways of thinking it is *wrong* 
to treat name bindings and memory locations as "the same sort of entity". 
Hence, if C variables are variables, then Python name bindings can't be.

I used to agree with that reasoning. I no longer do, not entirely. While 
I see the differences between them -- for instance, C variables exist 
before they have a value assigned to them, Python name bindings do not -- 
I don't think the differences are important enough to *prohibit* use of 
the word "variable" to describe name bindings. Only to discourage it.



-- 
Steven



More information about the Python-list mailing list