[Python-3000] PEP for Metaclasses in Python 3000 (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Wed Mar 14 00:51:16 CET 2007

Guido van Rossum wrote:

For uniformity and generality I propose to keep it. So the absolute minimal signature for prepare is actually:

def prepare(name, bases, *, metaclass=None): ... this way the prepare function can distinguish between an explicit and an implied metaclass.

Can you envisage any use case for distinguishing those? Seems to me you should be able to specify the metaclass either way and not have to worry about it behaving differently.

I think they should go to both

If they go to both, and the metaclass keyword is left in both times, then every existing metaclass is going to need its constructor signature changed to have a metaclass=None in it. Is that really what you want?

All I obect to is the nesting of the metaclass inside the class. It makes the metaclass essentially non-reusable ... it ends up having a generic name ... hard to pickle right.

For the use I had in mind (defining class methods) most of those things wouldn't be a problem. The metaclass is only intended for one purpose -- holding the class methods of the class being defined -- so you're not likely to want to reuse it, except when subclassing, in which case the subclass will get it as its implied metaclass. You're also not likely to need to pickle it, since its only instance is a top-level class, which will get pickled by name.

The naming is an issue, though, and also the fact that if any of your bases have a custom metaclass, you would need to do something a bit awkward to make your nested metaclass inherit from it.

What I really want is something like Smalltalk where you just say "I want these methods to be class methods" and a metaclass is automatically created behind the scenes to hold them, subclassed from the metaclass of the base class and given a suitable name. But that's something for another discussion.

It makes sense to put slots there, doesn't it?

What bothers me about slots in particular is that it's defining attributes, so conceptually it really belongs in the body. Or at least the contents of it does -- it's just the name 'slots' that we want to keep out. I'm not sure what to do about that.

-- Greg

More information about the Python-3000 mailing list