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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
