[Python-Dev] Classes and Metaclasses in Smalltalk

[Greg Ewing]

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.

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.

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.

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.

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.

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

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+