[Python-Dev] 2.3.5 and 2.4.1 release plans

[Alex Martelli]

On 2005 Feb 05, at 07:43, Anthony Baxter wrote:

> Ok, so here's the state of play: 2.3.5 is currently aimed for next 
> Tuesday,
> but there's an outstanding issue - the new copy code appears to have
> broken something, see www.python.org/sf/1114776 for the gory details.
> I'm completely out of time this weekend to look into it too closely - 
> if
> someone has 1/2 an hour and wants to do some triage on the bug, I'd
> appreciate it, a great deal.

Done: the issue is easy to fix but not to reproduce, and I'd like to 
reproduce it so as to fix the unit tests, which currently don't catch 
the problem.

The problem boils down to: deepcopying an instance of a type that 
doesn't have an __mro__ (and is not one of the many types explicitly 
recorded in the _deepcopy_dispatch dictionary, such as types.ClassType, 
types.InstanceType, etc, etc).

The easy fix: instead of cls.__mro__ use inspect.getmro which deals 
with that specifically.

Before I commit the fix: can anybody help out with an example of a type 
anywhere in the standard library that should be deepcopyable, used to 
be deepcopyable in 2.3.4, isn't one of those which get explicitly 
recorded in copy._deepcopy_dispatch, AND doesn't have an __mro__?  Even 
the _testcapi.Copyable type magically grows an __mro__; I'm not sure 
how to MAKE a type w/o one...


Thanks,

Alex