Possible bug in "metaclass resolution order" ?

[Pedro Werneck]

On 18 Sep 2005 00:39:31 -0700
"Michele Simionato" <michele.simionato at gmail.com> wrote:

> Remember that given a class C, its metaclass is given by C.__class__,
> not by > C.__metaclass__, despite the name.

Of course. Seems you think I'm arguing that C.__class__ and
__metaclass__ should always be the same. The metaclass is given by
C.__class__ after class creation. At the end of the 'class' statement,
searching for the 'winner' metatype, dict["__metaclass__"] is supposed
to have priority over B.__class__, and this over global __metaclass__.
Not only this is the behavior documented on GvR essay but is on the
source code I mentioned too.

> You argue that in this case an error should be raised, since "errors
> should never pass silently". May be. 

Exactly... and the behaviour is inconsistent. I get an exception when
the metaclass is not related to the M_A-M_B hierarchy, like X below, and
the same error was supposed to be raised when using M_A or type, which
do not follow the same rule of being a "subclass of the metaclasses of
all its bases". In fact, I lost a lot of time trying to find an error
related to this in my code a few weeks ago.

>>> class X(type): pass
... 
>>> class C(B): __metaclass__ = X
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Error when calling the metaclass bases
    metaclass conflict: the metaclass of a derived class must be a
(non-strict) subclass of the metaclasses of all its bases
>>> class C(B): __metaclass__ = M_A
... 
>>> C.__metaclass__
<class '__main__.M_A'>
>>> C.__class__
<class '__main__.M_B'>

> You are free to post the bug report and look at the opinions of the
> developers. 

I posted a few hours ago. 

Thank you.

-- 
Pedro Werneck