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