[Types-sig] MetaClasses (Non-ASCII art)

[Just van Rossum]

Me:
>> Sure, just add one more meta level which just implements
>> inheritance and you're still done...

M.-A. Lemburg wrote:
>Ok, point taken, would cause a lot of overhead though...

Absolutely. But we're having a theoretical discussion anyway, trying not to
think too much about actual implementation...

Me:
>> Or one that does, but that one might be implemented using a
>> meta protocol which doesn't do inheritance.

M.-A. Lemburg wrote:
>Right. I just find it a little confusing searching for the
>meta object (implementing the object's behaviour) in
>obj.__class__.__class__ because that reminds me too much of
>how Instances and Classes relate to each other.

Well, in the (maybe: "my") meta sense they are the same: a class is an
instance of a metaclass. But in the Python sense they are indeed very
different: getting a function attribute from a Python instance may look
inside it's __class__ and return a bound method, while getting a function
attribute from a class will always return an unbound method and never even
searches class.__class__. This is exactly the kind of behavior that one
would like to express as some sort of metathingy or turtle, and therefore
only serves as an _example_ of what you could do with a meta protocol. If
we want to be able to express these things, we should try to forget how
current Python object semantics are and come up with something _simple_
that is above it all. Or something.

>The meta protocol could very well also be used for other objects
>types which don't rely on underlying Classes. Coming to think
>of it... these __meta__ object have a lot in common with the
>type objects: only that type objects are a symbiosis of behaviour
>*and* implementation. Maybe there's a possibility there...

And we're really back to square one: types *and* classes...

>Also, it could allow changing the behaviour by reassigning a new
>meta object to obj.__meta__ on a per object basis.

Yeah, maybe that's cool. But then again: types *and* classes...

>And last, not least, it avoids one level of indirection
>in the implementation (though this could probably be simulated
>by caching __class__.__class__ into the __meta__ attribute).

Right: implementation details!

>> but this was a (veryveryvery*very* minor) point where today's
>> Python implementation let me down...
>
>I wouldn't be afraid of thinking big: a rewrite of some of the
>stuff in classobject.c wouldn't hurt much and there's still a
>lot of time 'til 1.6 comes out ;-)

I don't think that's worth it: this is all just a thought experiment, and I
think we get a long way implementing all sorts of experiments using the
simple hooks we have. Once one of these experiments is successful, it can
start having it's influence on classobject.c. And I truly think that's a
matter of 2.0.

MetaJust