This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: non-empty defaultdict .copy() fails returning empty dict
Type: behavior Stage:
Components: Extension Modules Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: rhettinger, tomcl
Priority: high Keywords:

Created on 2009-08-03 21:25 by tomcl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
bug.py tomcl, 2009-08-03 21:29 script showing bug when run under 2.6.2
Messages (4)
msg91242 - (view) Author: Tom Clarke (tomcl) Date: 2009-08-03 21:25
The enclosed script when run under 2.6.2 IDLE standard distribution on
x86 shows that shallow copy (.copy()) of a non-empty defaultdict object
returns an empty defaultdict!

Other ways to copy, e.g. defaultdict(none, d.items()), work fine.

Bug appears under:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32

I have tested it on two different computers. They both also have the
visual installed from a v2.6 binary - but I can't see why this would
change standard libraries.

Hope I am not being stupid - this seems to big a bug to be real!

**Documentation on defaultdict states (nearly all) methods are same as
dict, and on dict defines copy() as returning a shallow copy.

**replace defaultdict by dict and this example works as expected

Best wishes, Tom

PS - I am new to python so forgive any stupidity!
msg91252 - (view) Author: Tom Clarke (tomcl) Date: 2009-08-04 09:50
NB - (discussion of significance of this bug)

Defaultdict called with no argument is anomalous & this problem can be 
avoided in such cases by using dict. However this is not possible if 
default value can change and the documentation specifically defines 
behavior when called with no parameter, so this case is allowed.

Furthermore this bug is unpleasant because when the default values are 
never used it is very counterintuitive to imagine that the an error in 
the default value function could have any effect on the output.

Possible solutions:
(1) raise error in this case, change documentation (I prefer)
(2) mend behaviour in this case

Best wishes, Tom
msg91258 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-08-04 16:30
Thanks for the clear report.
I'll get this fixed-up.
msg91269 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-08-04 19:26
Fixed.  See r74299, r74300, r74301, and r74302.

Thanks for the bug report.
History
Date User Action Args
2022-04-11 14:56:51adminsetgithub: 50886
2009-08-04 19:26:35rhettingersetstatus: open -> closed
resolution: fixed
messages: + msg91269
2009-08-04 16:30:27rhettingersetpriority: high

assignee: rhettinger
components: + Extension Modules, - Library (Lib)
versions: + Python 3.1, Python 2.7, Python 3.2
nosy: + rhettinger

messages: + msg91258
2009-08-04 09:50:49tomclsetmessages: + msg91252
2009-08-03 21:29:27tomclsetfiles: + bug.py
2009-08-03 21:25:50tomclcreate