[Python-Dev] Re: 2.2a1: classmethod() and class attributes

Guido van Rossum guido@python.org
Wed, 15 Aug 2001 11:25:53 -0400


> +1 on changing __dynamic__ or at least enabling some kind of class
> variable mutability by default.

After converting the Tools/compiler package to the new class system, I
tend to agree (I already said so on c.l.py in my last post there).

Here's a problem, related to performance.

The dispatch for special operations (like __iter__) from C uses a C
function stored in a corresponding slot (e.g. tp_iter) in the type
object.  So when class X has an __iter__ method, there needs to be a
slot wrapper (a C function that calls the __iter__ object) in the in
the tp_iter slot in the type object representing X.

For dynamic classes, I must assume that at any time someone can add a
special method (like __iter__) to a class.  It's hard to set up things
so that the dispatch function is set in the type object at the moment
C.__iter__ is assigned: it would require a class to keep track of all
its subclasses, without keeping those subclasses alive.  While I know
I can do that using weak references, I don't like having to maintain
all that administration.  So at the moment, when a class is dynamic, I
just stick all dispatch functions in the type object -- the dispatch
functions will raise AttributeError when their corresponding method is
not found.  (This is the same approach used for classic classes, BTW.)

This is slower than it should be -- the fully dynamic Tools/compiler
package compiles itself about 25% slower this way.  If I tweak it to
use all static classes (not very hard), it runs at about the same
speed as it does with classic classes.  I imagine I could make it
faster by using __slots__, but I don't know enough about the internals
yet to be able to do that.

My goal (before I'm happy with making __dynamic__=1 the default) is
that dynamic classes should be at least as fast as classic classes.  I
haven't profiled it yet -- it's possible that there's a cheap hack
possible by making more conservative assumptions about __getattr__
alone -- classic classes special-case __getattr__ too.)

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