On 2005 Feb 06, at 08:34, Tim Peters wrote: ...
The easy fix: instead of cls.__mro__ use inspect.getmro which deals with that specifically. ... Since the original bug report came from Zopeland, chances are good (although the report is too vague to be sure) that the problem involves ExtensionClass. That's complicated C code in Zope predating
True, of course. Still, any type w/o an __mro__ that's not recorded in the dispatch table will tickle the same bug -- give the same traceback, at least (if the original submitter would then proceed to tickle more bugs once this one's solved, I can't know, of course -- but this one does need fixing).
Unsure whether this is enough, but at least inspect.getmro() isn't phased by an EC-derived class:
I'm pretty sure it's enough -- at least for SOME "types w/o __mro__". Thanks to a suggestion from John Lenton on c.l.py, I was able to make a unit test based on: class C(type): def __getattribute__(self, attr): if attr == '__mro__': raise AttributeError, "What, *me*, a __mro__? Nevah!" return super(C, self).__getattribute__(attr) class D(object): __metaclass__ = C Cheating, maybe, but it does show that the 2.3.5rc1 copy.py breaks and moving to inspect.mro repairs the break, which is all one really asks of a tiny unit test;-). So, I've committed test and fix on the 2.3 maintenance branch and marked the bug as fixed. (Hmmmm, is it only me, or is sourceforce bug browsing broken for bugs with 7-digits numbers? This one was 1114776 -- first one w/a 7-digit number I had yet seen -- and in no way could I get the browser to list it, it kept listing only 6-digit ones...). Alex