[Python-3000] Changing order of class creation

[Alex Martelli]

On 4/24/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Here's something for the crazy idea bin...
>
> Right now class creation looks like:
>
>    class X(base):
>        y = 'z'
>
> This gets the things in the () (object), evaluates the body of the class
> in a new scope and captures that scope (namespace), and looks for a
> metaclass using a couple rules.  Then it does:
>
>    X = metaclass('X', (base,), {'y': 'z'})
>
> What if instead it did:
>
>    X = metaclass('X', (base,))
>    X.y = 'z'
>
> ?  X could keep track of order if it wanted.  Or not.  There would be no
> conflict between metaclasses paying special attention to the constructor
> namespace, and later attribute setting on the same class (most
> metaprogramming techniques with metaclasses choose one or the other).
> It could make rebuilding a class easier (as in reload).  If
> metaclass('X', (bases,)) returned the already-existant X class,
> attributes will get folded in.  (There's still problems there, but maybe
> this helps a little.)
>
> I haven't really thought through all the effects this might have.  It
> does mean the underlying mechanism runs in the same order as the source,
> instead of the inverted order we currently have (where the body is
> evaluated before the class is created).

It appears to me that, in order to allow recreation of today's
functionality in all cases, we *also* need a way to tell X, or
probably better, X's metaclass, that  ``the class statement is
finished, please complete whatever it is you need to do to build X''.

And it does seem perfectly reasonable to me that a metaclass may want
to treat some X.a=... assignment coming "from" the class body,
differently from one happening much later on.  So, presumably, we need
two ways to call the metaclass (or methods thereon), one for the
initial creation and one for the "end of class statement" -- perhaps
just two 'overloads' of the metaclass's __call__, one with two
arguments (name and bases) for initial creation, one with just one
argument (the X object as prepared so far) for end of class statement.

Also, it seems we need some other way to pick the metaclass, to
substitute for today's "assign to __metaclass__ in the classbody". 
And, I'd like (though it's not a must) some way to replicate today's
functionality to "call the metaclass on the fly" to make a class.

But if all of these nits can be solved, I do see the advantage on
letting X "keep track of the order if it wants to".


Alex