class C: vs class C(object):

[Bruno Desthuilliers]

George Sakkis a écrit :

FWIW, I am not advocating old style classes and I rarely (if ever) use
them in new code, but I occasionally miss the following feature, which
by the way disproves the assertion that "new-style classes can do
anything Classic classes did":

class Classic: pass
class NewStyle(object)ass

for o in Classic(),NewStyle():
o.__str__ = lambda: 'Special method overriding works on
instances!'
print '%s object: %s' % (o.__class__.__name__, o)

Good point. There are effectively a couple of things that did work with
the old object model and don't with the new one. OTOH, and while I tend
to make heavy use of Python's dynamism and advanced features, I never
had the need to dynamically override special methods on a per-instance
basis yet. Not to say this is useless, just that it's probably enough of
a corner case to justify the design choice (YMMV of course).

 

[nvictor]

Hi,

I'm not an experienced developer, and I came across this statement by
reading a code. I search for explanation, but can't find anything
meaningful. I read the entire document written by python's creator
about the features of version 2.2 The one named unifying types and
classes. But This document only blew my head away.

I ended here and think somebody can explain me more about this. The
only thing I have noticed is that when you do dir(C) on a classic
class you get a bunch of attributes; and when you do the same thing on
a class defined using class C(object), you get less attributes.

Thanks for all replies.

 

[Bruno Desthuilliers]

nvictor a écrit :

Hi,

I'm not an experienced developer, and I came across this statement by
reading a code. I search for explanation, but can't find anything
meaningful. I read the entire document written by python's creator
about the features of version 2.2 The one named unifying types and
classes. But This document only blew my head away.
>
I ended here and think somebody can explain me more about this.

To make a long story short: Python 2.2 introduced a new object model
which is more coherent and more powerful than the original one. The old
one was kept so far for compatibility reasons, but there's absolutely no
reason to use it no more since "new-style" classes can do anything
"Classic" classes did and much more. IOW, don't even bother with
old-style classes.

 

[Lutz Horn]

Hi,

there's absolutely no reason to use it no more since "new-style" classes
can do anything "Classic" classes did and much more. IOW, don't even
bother with old-style classes.

Just for the records: the new and preferred style is

class C(object):
...

Regards
Lutz

 

[Steven D'Aprano]

Hi,

I'm not an experienced developer, and I came across this statement by
reading a code. I search for explanation, but can't find anything
meaningful. I read the entire document written by python's creator
about the features of version 2.2 The one named unifying types and
classes. But This document only blew my head away.

I ended here and think somebody can explain me more about this. The
only thing I have noticed is that when you do dir(C) on a classic
class you get a bunch of attributes; and when you do the same thing on
a class defined using class C(object), you get less attributes.

Thanks for all replies.

The short answer is, unless you are writing code that has to be backwards
compatible with very old versions of Python, always use new style classes
by inheriting from object instead of old-style classes.

It isn't wrong to use the old style, but it is deprecated, and they will
eventually go away. Old style classes are the way classes used to be, back
in Ancient Days. You couldn't inherit from built-in types like str or int,
which used a different mechanism under the hood.

Certain very useful features simply will not work correctly with old-style
classes, like properties and slots. Also, multiple inheritance works
better with new-style classes: there is a subtle design flaw in the way it
works for old-style classes, which can lead to bugs.

For the technical answer about the difference, go back and read the
document about unifying classes and types.

 

[Aahz]

To make a long story short: Python 2.2 introduced a new object model
which is more coherent and more powerful than the original one. The old
one was kept so far for compatibility reasons, but there's absolutely no
reason to use it no more since "new-style" classes can do anything
"Classic" classes did and much more. IOW, don't even bother with
old-style classes.

And I'll make my usual knee-jerk response disagreeing with this. For
more info, search groups.google.com.

 

[Aahz]

It isn't wrong to use the old style, but it is deprecated, [...]

Really? Can you point to some official documentation for this? AFAIK,
new-style classes still have not been integrated into the standard
documentation. Maybe I missed something, though.

Note very carefully that "going away eventually" is *not* the same as
deprecation.

 

[James Stroud]

It isn't wrong to use the old style, but it is deprecated, [...]

Really? Can you point to some official documentation for this? AFAIK,
new-style classes still have not been integrated into the standard
documentation. Maybe I missed something, though.

Note very carefully that "going away eventually" is *not* the same as
deprecation.

How about "broke" instead of "deprecated":

.... def __init__(self):
.... self._value = 'broke'
.... value = property(lambda self: self._value)
........ def __init__(self):
.... self._value = 'works'
.... value = property(lambda self: self._value)
....Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: can't set attribute


James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Aahz]

It isn't wrong to use the old style, but it is deprecated, [...]

Really? Can you point to some official documentation for this? AFAIK,
new-style classes still have not been integrated into the standard
documentation. Maybe I missed something, though.

Note very carefully that "going away eventually" is *not* the same as
deprecation.

How about "broke" instead of "deprecated":

... def __init__(self):
... self._value = 'broke'
... value = property(lambda self: self._value)
...

How is this broken? Properties are not supported for old-style classes.
They may not support features introduced in new-style classes, but that's
hardly the same as "broken".

 

[sjdevnull]

It isn't wrong to use the old style, but it is deprecated, [...]


Really? Can you point to some official documentation for this? AFAIK,
new-style classes still have not been integrated into the standard
documentation. Maybe I missed something, though.

Note very carefully that "going away eventually" is *not* the same as
deprecation.

How about "broke" instead of "deprecated":

class Old:

... def __init__(self):
... self._value = 'broke'
... value = property(lambda self: self._value)
...

How is this broken? Properties are not supported for old-style classes.
They may not support features introduced in new-style classes, but that's
hardly the same as "broken".

In particular, old-style classes are noticeably faster than new-style
classes for some things (I think it was attribute lookup that
surprised me recently, possibly related to the property stuff...)

 

[Bruno Desthuilliers]

Aahz a écrit :

And I'll make my usual knee-jerk response disagreeing with this. For
more info, search groups.google.com.

And you'll still make it harder for newcomers to understand why a lot of
things don't work correctly with their classes. How helpful...

Aahz, the object model switch happened *years* ago, and it's quite clear
that old style classes have been kept so far for compatibility reasons
only. It's obvious that one doesn't gain *anything* - except compat with
years-old pre-2.2 versions of Python - using old-style classes. So *why*
on earth are you still *advocating* the use of old style classes ??????

 

[Hrvoje Niksic]

In particular, old-style classes are noticeably faster than
new-style classes for some things (I think it was attribute lookup
that surprised me recently, possibly related to the property
stuff...)

Can you post an example that we can benchmark? I ask because the
opposite is usually claimed, that (as of Python 2.4 or 2.5) new-style
classes are measurably faster.

 

[Steven D'Aprano]

It isn't wrong to use the old style, but it is deprecated, [...]

Really? Can you point to some official documentation for this? AFAIK,
new-style classes still have not been integrated into the standard
documentation. Maybe I missed something, though.

Note very carefully that "going away eventually" is *not* the same as
deprecation.

*slaps head*

Yes, Aahz is correct, and I for one should have known better: see this
thread, for example, where I not only defend the use of old style classes
but explicitly stated that they *weren't* deprecated.

http://groups.google.com.au/group/c...hz+new+style+classes+&rnum=1#52fabc6398a566b6


Mea culpa.

 

[George Sakkis]

Aahz a écrit :



And you'll still make it harder for newcomers to understand why a lot of
things don't work correctly with their classes. How helpful...

Aahz, the object model switch happened *years* ago, and it's quite clear
that old style classes have been kept so far for compatibility reasons
only. It's obvious that one doesn't gain *anything* - except compat with
years-old pre-2.2 versions of Python - using old-style classes. So *why*
on earth are you still *advocating* the use of old style classes ??????

FWIW, I am not advocating old style classes and I rarely (if ever) use
them in new code, but I occasionally miss the following feature, which
by the way disproves the assertion that "new-style classes can do
anything Classic classes did":

class Classic: pass
class NewStyle(object)ass

for o in Classic(),NewStyle():
o.__str__ = lambda: 'Special method overriding works on
instances!'
print '%s object: %s' % (o.__class__.__name__, o)


George

 

[Bruno Desthuilliers]

Aahz a écrit :
(snip)

*YOU* are the one confusing people by your dogmatic insistance that
classic classes should be ignored. Grow up.

I did. I still do. With every new Python release. I'm sorry for you that
you are still stuck with almost prehistoric Python versions, but I don't
accept this as a reason to pretend Python has not "grown up" during the
last five years...

 

[Aahz]

Aahz a écrit :

And you'll still make it harder for newcomers to understand why a lot of
things don't work correctly with their classes. How helpful...

Enh. *All* of the standard Python documentation currently starts with
teaching classic classes, so it seems to me that this comment in fact
points toward difficulty understanding why things don't work correctly in
new-style classes.

Aahz, the object model switch happened *years* ago, and it's quite
clear that old style classes have been kept so far for compatibility
reasons only. It's obvious that one doesn't gain *anything* - except
compat with years-old pre-2.2 versions of Python - using old-style
classes. So *why* on earth are you still *advocating* the use of old
style classes ??????

Saying that I'm "advocating" the use of old-style classes is not
precisely correct. The simple fact is that you are wrong about the
switch having happened already. There is almost no basic documentation
that starts with new-style classes; the vast majority of the Python
Standard Library still uses classic classes; there is no requirement in
PEP8 that new code for adding into Python 2.x use new-style classes.

Moreover, there are still plenty of people (me included) who use Python
2.2 for production purposes, and because of the small but critical
differences between new-style classes in 2.2 and 2.3+, I cannot
recommend new-style classes for anyone who has not switched to using
only 2.3+. (For that matter, there are still people using 2.1 and
earlier, which is why some developers such as Fredrik Lundh still support
all the way back to 1.5.2.)

*YOU* are the one confusing people by your dogmatic insistance that
classic classes should be ignored. Grow up.

 

[Bruno Desthuilliers]

Aahz a écrit :
(snip)

Enh. *All* of the standard Python documentation currently starts with
teaching classic classes, (snip)
There is almost no basic documentation
that starts with new-style classes;

(snip)

Just for the record:
http://docs.python.org/ref/node33.html
http://www.python.org/doc/newstyle/

 

[Klaas]

Can you post an example that we can benchmark? I ask because the
opposite is usually claimed, that (as of Python 2.4 or 2.5) new-style
classes are measurably faster.

Why do people ask for trivial examples?

$ cat classes.py
class Classic:
def __init__(self):
self.attr = 1

class NewStyle(object):
def __init__(self):
self.attr = 1

$ python -m timeit -s 'from classes import *; c = Classic()' 'c.attr'
<timeit-src>:2: SyntaxWarning: import * only allowed at module level
1000000 loops, best of 3: 0.182 usec per loop

$ python -m timeit -s 'from classes import *; c = NewStyle()' 'c.attr'
<timeit-src>:2: SyntaxWarning: import * only allowed at module level
1000000 loops, best of 3: 0.269 usec per loop

New style classes have more machinery to process for attribute/method
lookup, and are slower.

There are very few algorithms for which attribute access is the
bottleneck however (seeing as how easier they can be extracted out of
inner loops into locals, which are much faster than attribute access
on either type of class).

Using old-style classes for performance is a useful hack for python
perf wizards, but is a dangerous meme to perpetuate.

-Mike