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!)
Cheers, Nick.
[1] http://www.python.org/dev/doc/devel/ref/metaclasses.html [2] http://www.python.org/2.2/descrintro.html#metaclasses
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
