[Python-Dev] 2.3.5 and 2.4.1 release plans

[Alex Martelli]

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