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