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. I'm currently thinking about a 2.4.1 around the 23td of Feb - Martin and Fred, does this work for you? There's a bunch of backporting that should probably happen for that - I will try to get some time to do this in the next week or so. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
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
[Anthony Baxter]
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. ...
[Alex Martelli]
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...
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 new-style classes, making it possible to build Python-class-like objects in C code under old Pythons. In general, EC-derived classes don't play well with newer Python features (well, at least not until Zope 2.8, where ExtensionClass is recoded as a new-style Python class -- but still keeping some semantics from old-style classes ... ). Anyway, I expect that instances of any EC-derived class would have the problem in the bug report. For example, the base Persistent class in ZODB 3.2.5 is an ExtensionClass: $ \python23\python.exe Python 2.3.5c1 (#61, Jan 25 2005, 19:52:06) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import ZODB # don't ask -- it's necessary to import this first from Persistence import Persistent p = Persistent() import copy copy.deepcopy(p) # deepcopy() barfs on __mro__ Traceback (most recent call last): File "<stdin>", line 1, in ? File "C:\Python23\lib\copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "C:\Python23\lib\copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ copy.copy(p) # copy() does too Traceback (most recent call last): File "<stdin>", line 1, in ? File "C:\Python23\lib\copy.py", line 86, in copy copier = _getspecial(cls, "__copy__") File "C:\Python23\lib\copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__
Unsure whether this is enough, but at least inspect.getmro() isn't phased by an EC-derived class:
inspect.getmro(Persistent) (<extension class Persistence.Persistent at 100040D8>,)
More info from the bug report filer is really needed. A problem is that this stuff doesn't appear "to work" under Python 2.3.4 either: $ ../Python-2.3.4/python Python 2.3.4 (#1, Aug 9 2004, 17:15:36) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import ZODB from Persistence import Persistent p = Persistent() import copy copy.deepcopy(p) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/tim/Python-2.3.4/Lib/copy.py", line 206, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/home/tim/Python-2.3.4/Lib/copy.py", line 338, in _reconstruct y = callable(*args) TypeError: ExtensionClass object argument after * must be a sequence copy.copy(p) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/tim/Python-2.3.4/Lib/copy.py", line 95, in copy return _reconstruct(x, rv, 0) File "/home/tim/Python-2.3.4/Lib/copy.py", line 338, in _reconstruct y = callable(*args) TypeError: ExtensionClass object argument after * must be a sequence
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
Anthony Baxter wrote:
I'm currently thinking about a 2.4.1 around the 23td of Feb - Martin and Fred, does this work for you?
Yes. I will need to test whether my replacement of VB scripts in the installer with native DLLs works even on W95; I'm confident to complete this next week (already have the W95 machine installed). Regards, Martin
participants (4)
-
"Martin v. Löwis" -
Alex Martelli -
Anthony Baxter -
Tim Peters