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