2.2 features

[Guido van Rossum]

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

> Mon, 23 Jul 2001 08:55:40 GMT, Nick Perkins <nperkins7 at home.com> pisze:
> 
> > Isn't there anything in 2.2 that deserves even a fraction of the discussion
> > going on about div? (which has been beaten to death 9 times)
> > 
> > getset(), staticmethod(), classmethod(), etc...
> 
> I must say that the current state of type/class unification is so
> complex that I don't understand the details, all these slots and
> wrappers and types, and why
>     5 .__new__(list, '42') == 42
> for example.

Sorry, that's a bug; this should be rejected as list is not a subtype
of int.

> I home that the following piece of documentation is temporary!
> 
>    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?

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