Recursion error in metaclass
Terry Reedy
tjreedy at udel.edu
Sat Jun 11 15:39:34 EDT 2011
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
More information about the Python-list
mailing list