New inited instance of class?

Michele Simionato michele.simionato at poste.it
Mon Dec 8 11:16:25 EST 2003


"Francis Avila" <francisgavila at yahoo.com> wrote in message news:<vt6qfomt0b1686 at corp.supernews.com>...> And it's probably not a problem.  From "What's new in 2.3", section 16:
> """
> The method resolution order used by new-style classes has changed, though
> you'll only notice the difference if you have a really complicated
> inheritance hierarchy.

The "What's new" is right in practice, nevertheless, just for the sake
of
giving a counter-example, here is a very simple hierarchy which is
forbidden in 2.3 and valid in 2.2:

>>> class C(object,type):pass
... 
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: Cannot create a consistent method resolution
order (MRO) for bases object, type


> So I still stand by the claim that one should stop using old-style classes.

I don't disagree but see next point.
 
> What are the serious compatibility problems with changing an old-style class
> to a new-style class (which I haven't encountered)?  My understanding is
> that the headaches are from *mixing* classic and new-style classes in the
> same hieararchy.

Not really, in my experience the mixture works well enough. Right now,
I see two other problems: 1) exceptions MUST be old style (as Aahz
already
pointed out) and 2) the are subtle differences in the working of
special methods such as __setattr__ and __getattr__ (and I think
Aahz was alluding to this too).
For new style classes x.__setattr__(k,v) is the same than 
type(x).__setattr__(x,k,v) but the lookup rule is different for old
style classes. See the Nutshell for more.


               Michele




More information about the Python-list mailing list