[Python-Dev] Class Methods

Guido van Rossum guido at digicool.com
Fri Apr 20 12:26:01 EDT 2001


> 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/~guido/)




More information about the Python-list mailing list