There are some signs :-) that Python's object model is going to be revised even _before_ Python 3000.
Well, the official policy on this is now that Py3K is just a slogan, and that all the real work will be introduced gradually. :-)
Is someone willing to join me fighting for class methods (I mean 'real' class-methods in the Smalltalk style here, _not_ static methods like in Java or C++).
I will fight class methods to the death. :-)
Seriously, I think you'll find an ally in Jim Fulton, who basically told me (since he's sort of my boss :-) to get on with this work. I think it can work as follows:
Let x be an object, C its class, and M C's class. So,
x.__class__ is C C.__class__ is M
Then x's methods are described in C.__dict__, and C's methods are described in M.__dict__.
The problem is that if you write C.spam, there could be two spams: one in C.__dict__, one in M.__dict__. Which one to use? How does Smalltalk resolve this? The problem is that for backwards compatibility, at lease, C.spam must be the unbound version of x.spam, because currently x.spam(...) can always also be written as C.spam(x, ...).
For regular methods it may be possible to avoid this simply by choosing non-conflicting names, but I seem to recall that Jim wanted to use class methods with certain special names (like __init__ or __getattr__?), and I have no idea how to do this without dropping the idea that x.spam(...) is C.spam(x, ...). So maybe that's the solution?
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)