[Python-3000] PEP for Metaclasses in Python 3000

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