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
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list