[Python-3000] Nix dict.copy()
Larry Hastings
larry at hastings.org
Mon Feb 11 03:24:56 CET 2008
Christian Heimes wrote:
> Larry Hastings wrote:
>
>> +1 for exactly the reasons cited. I think copy() and deepcopy() should
>> both be "essential" built-in functions.
>>
>
> I'm -0 on copy and -1 on deepcopy.
>
> If you need a copy or a deepcopy of an object (except dicts, lists and
> sets) you are most certainly using the wrong approach.
My +1 isn't based primarily on how often I would use copy/deepcopy, as I
don't need them very often. (Although I do use it *ever*, unlike many
builtins--complex(), divmod(), and reversed() just to name three.)
Instead, it's based on the observation that copy and deepcopy seem to be
a first-class part of the language. The following built-in classes
implement __copy__; those that also implement __deepcopy__ are marked
with an asterisk:
array.array*
collections.defaultdict
collections.deque
decimal.Decimal
xml.etree.ElementTree*
itertools.tee
re.match*
re.pattern*
All of those are implemented in C except for decimal.Decimal. This list
was compiled from Python 3.0a2.
I pass no judgment on programmers using copy/deepcopy. Though I note
that, if you are passed a merely dict-like / list-like / set-like
object, I would feel more confident in using copy.copy() to copy it than
using dict() / list() / set() to copy it; enforcing the type this way
seems so un-duck-typing to me. I suppose I could go fishing in the
object to see if it implements a copy() method (dicts and sets do, lists
don't), but then the deprecation/removal of .copy() methods in favor of
copy.copy was how this whole thread got started.
And, needless to say, there is simply no substitute for copy.deepcopy(),
/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080210/25f1d4f7/attachment.htm
More information about the Python-3000
mailing list