2.2 features

[Guido van Rossum]

[PEP 253]
> >>    Isn't this backwards incompatible? Won't it break existing code? It
> >>    would, if we changed the method resolution order for all classes.
> >>    However, in Python 2.2, the new lookup rule will only be applied to
> >>    types derived from built-in types, which is a new feature. Class
> >>    statements without a base class create "classic classes", and so do
> >>    class statements whose base classes are themselves classic classes.
> >>    For classic classes the classic lookup rule will be used. (To
> >>    experiment with the new lookup rule for classic classes, you will be
> >>    able to specify a different metaclass explicitly.) We'll also provide
> >>    a tool that analyzes a class hierarchy looking for methods that would
> >>    be affected by a change in method resolution order.

> Tue, 24 Jul 2001 19:33:34 GMT, Guido van Rossum <guido at python.org> pisze:
> 
> > There are many things that could be improved here.  What exactly is
> > bothering you about it?

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> writes:

> That a subtle difference in the program (deriving from a class which
> inherits from a builtin type instead of using delegation) causes a
> non-obvious subtle change in the behavior which doesn't seem related
> to the source (method lookup order).

This is a compromise between breaking backwards compatibility and
doing the right thing.

> If some consistent rule of method lookup order is going to eventually
> win, no matter which, then I didn't say anything. But if such fuzzy
> behaviors are going to stay, they feel almost as bad as would
> "'/' rounds down if you used '%' in the program or towards 0 otherwise"
> feel to me.

Eventually the new MRO rule will be the default, but a metaclass that
implements the old rule will be made available for code that requires
backwards compatibility (until demand disappears).  You can write
"__metaclass__ = <some_class>" at the top of your module to choose the
default metaclass.

Fortunately this problem is much easier to detect at compile time than
int division, so a tool that detects potential issues is not hard to
write.  I will definitely give this plenty of time (like I will with
all incompatibilities I introduce).

--Guido van Rossum (home page: http://www.python.org/~guido/)