New inited instance of class?

[Francis Avila]

Fredrik Lundh wrote in message ...
>Francis Avila wrote:
>
>> If you're curious, look in the Python Language Reference at the old and
new
>> style classes to see the differences.  There's absolutely no advantage to
>> old style classes
>
>except performance:
>
>http://www.python.org/~jeremy/weblog/030506.html

That's not a big difference, and in any case:
http://www.python.org/doc/current/whatsnew/node17.html#SECTION00017200000000
00000000

Creation of new-style instances is faster.  I seem to recall Alex Martelli
also thinking that new-style classes are faster all-around.  In any case,
he's gung-ho on new-style classes, even more than I am.

>> it's vital for understanding the still poorly-documented new-style
classes.
>
>documentation may also be seen as an advantage, of course.

True, but unless one is doing something elaborate (can't even think *what*)
or relies on the old mro, the only difference is that base classes will
derive from object.  If there is code that depends upon the old mro, it
should probably be fixed anyway.

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. Classic classes are unaffected by this change. Python
2.2 originally used a topological sort of a class's ancestors, but 2.3 now
uses the C3 algorithm as described in the paper ``A Monotonic Superclass
Linearization for Dylan''. To understand the motivation for this change,
read Michele Simionato's article ``Python 2.3 Method Resolution Order'', or
read the thread on python-dev starting with the message at
http://mail.python.org/pipermail/python-dev/2002-October/029035.html.
Samuele Pedroni first pointed out the problem and also implemented the fix
by coding the C3 algorithm. """

So I still stand by the claim that one should stop using old-style classes.
Changing old-style to new-style classes is more problematic, but I don't see
that it's much more.  If the code is old enough to use changed/depreciated
pre-2.2 features, changing classic classes to new-style is the least of your
problems.  But if it's 2.2 code, the jump to 2.3 is small and nothing but an
advantage--only a policy decision should keep anyone in 2.2.

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.
--
Francis Avila