On 18 Sep 2005 00:39:31 -0700
"Michele Simionato" <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
