[Python-Dev] __metaclass__ problem

Nick Coghlan ncoghlan at iinet.net.au
Sat Mar 19 00:55:04 CET 2005

Dirk Brenckmann wrote:
> In consequence a programmer only is in control of the "metaclass" of his
> class, if he decides it to be a subtype of all former metaclasses he used in
> his class hierarchy, or if he uses the same metaclass as the superclass
> does.

The behaviour is intentional, but you are correct that it is not fully 
documented in the official documentation [1].

Some of the 'wrinkles' described in Guido's original Python 2.2 essay [2] may 
need to be transferred to the docs.

For instance:

"""For new-style metaclasses, there is a constraint that the chosen metaclass is 
equal to, or a subclass of, each of the metaclasses of the bases. Consider a 
class C with two base classes, B1 and B2. Let's say M = C.__class__, M1 = 
B1.__class__, M2 = B2.__class__. Then we require issubclass(M, M1) and 
issubclass(M, M2). (This is because a method of B1 should be able to call a 
meta-method defined in M1 on self.__class__, even when self is an instance of a 
subclass of B1.)"""

If you are not getting an exception when breaking this rule, my guess would be 
that your metaclasses are not inheriting from 'type', or else are not invoking 
type's __new__ method. The logic to trigger the exception lives in type's 
__new__ method - if that doesn't get invoked, you won't get the exception.

(Note that this also addresses your final objection: if you genuinely don't like 
the behaviour imposed by using 'type' as the metaclass, then don't use 'type' as 
the metaclass!)


[1] http://www.python.org/dev/doc/devel/ref/metaclasses.html
[2] http://www.python.org/2.2/descrintro.html#metaclasses

Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia

More information about the Python-Dev mailing list