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