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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4