[Python-Dev] Classes and Metaclasses in Smalltalk

[Guido van Rossum]

> Guido:
> 
> > If both are defined, I propose the following, clumsy but backwards
> > compatible rule: if DictType.__dict__['foo'] describes a method, it
> > wins.  Otherwise, TypeType.__dict__['foo'] wins.

Greg Ewing:

> Yeek! I think that's far too confusing a rule. I suppose
> it might do in the meantime, but we'd better have a long
> term solution in mind before going too far down this
> route.

I agree 100%.  I had to do something quick to be able to make progress
with my PEP 252 project, but it's a clear indication that there's a
problem!

> Ultimately it seems like we'll have to introduce a separate
> namespace for methods and default instance attributes,
> say __classdict__. Then lookup of x.foo would look
> first in x.__dict__, then x.__class__.__classdict__,
> etc up the inheritance chain.

Except that sometimes you really do want x.__class__.__classdict__ to
have priority (e.g. for "guarded" attributes).

> Then we'll have to resolve the ambiguity of the class.foo
> syntax. The bravest way would be simply to change the syntax
> for getting unbound methods.

Agreed again.

> The most common use for these seems to be for calling
> inherited methods, so perhaps something like
> 
>    inherited MyBaseClass.foo(arg, ...)
> 
> which would be equivalent to
> 
>    getmethod(MyBaseClass, 'foo')(self, arg, ...)
> 
> where getmethod() is a new builtin like getattr()
> except that it looks in the __classdict__, and 'self'
> is really whatever the first argument of the containing
> method was.

The second most common use is to reference class variables
(e.g. imagine a class that keeps counters of how many instances have
been created and deleted in C.initcount and C.delcount).  But these
should not have to change, since they really are class attributes.

> Now that we have __future__, would such a change be contemplatable?
> Or is it too radical to even think about?

If we can find a way to spell "super.method", we should be ready for
the future.  I can't think of something right off the bat
unfortunately.

But the issue of backwards compatibility is a big one here: the idioms
for calling base class methods and using class variables as defaults
for instance variables are so common that we will have to support
these for many future versions!  (Two things I am not looking forward
to: fixing all the Zope code that uses this, and telling the author of
Programming Python, 2nd. ed.)

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