On 6/11/2011 7:38 AM, Steven D'Aprano wrote:
On Sat, 11 Jun 2011 01:33:25 -0400, Terry Reedy wrote:
On 6/10/2011 11:34 PM, Steven D'Aprano wrote:
I have a metaclass in Python 3.1:
class MC1(type):
@staticmethod
def get_mro(bases):
print('get_mro called')
return type('K', bases, {}).__mro__[1:]
The call to type figures out the proper metaclass from bases and
forwards the call to that (or to its __new__ method).
[...]
Since uou do not pass dict to get_mro. it passes {} to type and MC1 and
the test for docstring fails and the loop is broken and the empty class
is discarded after getting its mro.
Thanks for the explanation. You confused me for a while talking about
MC1, because that's the metaclass that *doesn't* raise an exception, but
Sorry, you probably changed that to MC2 for the second example and I did
not notice. The point is that when either version calls get_mro and
type, types calls back to the same metaclass, so that unguarding the
call to get_mro results in looping.
I think I see the issue now.
What may not be obvious from the docs is that the metaclass calculation
described in the doc section on class statements is carried out within
type.__new__ (or after a possible patch, called from within that), so
that type calls are really "a dynamic form of the class statement" even
when another another metaclass is specified or implied. "Return a new
type object." includes instances of type subclasses. I am not sure what
happens with metaclasses that are not type subclasses. There is at least
one bug report about the metaclass calculation, which is why I happen to
have read the typeobject.__new__ code. But I have not read the
build-class code and all the details of class creation. So I may have
some of the details above wrong.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
