class C: vs class C(object):

Bruno Desthuilliers bdesth.quelquechose at
Thu Jul 19 06:51:29 CEST 2007

George Sakkis a écrit :
> On Jul 20, 5:40 am, Bruno Desthuilliers <bruno.
> 42.desthuilli... at> wrote:
>>Aahz a écrit :
>>>In article <469f1557$0$26759$426a7... at>,
>>>Bruno Desthuilliers  <bruno.42.desthuilli... at> wrote:
>>>>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
>>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):pass
> 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).

More information about the Python-list mailing list