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