This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author abusalimov
Recipients abusalimov
Date 2014-07-04.20:45:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
In-reply-to
Content
When a new class is constructed Python checks for possible metaclass conflicts within bases and an explicitly specified one, if any, choosing the best available (the most specialized) one. That is the following implication is expected:

    issubclass(B, A) => issubclass(type(B), type(A))

However, changing __bases__ attribute can break this invariant silently without an error.

>>> class O(object):
...     pass
... 
>>> class M(type):
...     pass
... 
>>> class N(type):
...     pass
... 
>>> class A(O, metaclass=M):
...     pass
... 
>>> class B(O, metaclass=N):
...     pass
... 
>>> B.__bases__ = (A,)
>>> B.__mro__
(<class '__main__.B'>, <class '__main__.A'>, <class '__main__.O'>, <class 'object'>)
>>> type(B)
<class '__main__.N'>
>>> type(A)
<class '__main__.M'>
>>> issubclass(B, A)
True
>>> issubclass(type(B), type(A))
False

Trying to derive from B now makes things look pretty weird:

>>> class C(A, metaclass=N):
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
>>> class D(B, A): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
>>> class E(B, metaclass=N):
...     pass
... 
>>> type(E)
<class '__main__.N'>

That is one can extend a class but not its base (and not a class along its base). This effectively allows to bypass metaclass checks (by introducing a dummy class with the default metaclass, deriving it from a desired class with an inappropriate metaclass by changing __bases__ and using it instead of the desired class).

This behavior is observed in 2.7, 3.2 and 3.4.


I would expect the same check for metaclass conflicts when changing __bases__ as upon creating a new class:

>>> # EXPECTED:
... 
>>> B.__bases__ = (A,)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
History
Date User Action Args
2014-07-04 20:45:25abusalimovsetrecipients: + abusalimov
2014-07-04 20:45:25abusalimovsetmessageid: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
2014-07-04 20:45:25abusalimovlinkissue21919 messages
2014-07-04 20:45:24abusalimovcreate