[Python-Dev] 2.3.5 and 2.4.1 release plans
aleax at aleax.it
Sat Feb 5 09:06:53 CET 2005
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
> 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 -
> 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 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...
More information about the Python-Dev