[Python-3000] Nix dict.copy()

[Larry Hastings]

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