2.2 features

[Marcin 'Qrczak' Kowalczyk]

Tue, 24 Jul 2001 19:33:34 GMT, Guido van Rossum <guido at python.org> pisze:

>>    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.
> 
> There are many things that could be improved here.  What exactly is
> bothering you about it?

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).

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.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK