[Python-3000] Nix dict.copy()
Guido van Rossum
guido at python.org
Tue Feb 12 05:47:10 CET 2008
On Feb 11, 2008 7:58 PM, Raymond Hettinger <python at rcn.com> wrote:
> Where did we end-up on dict.copy()?
>
> Is the copy(obj) function sufficiently universal to replace the obj.copy() method used in sets and in dict imitators? Or does the
> need for import preclude it from consideration?
>
> To me it seems that relationship between __copy__ and the copy() function is just as universal as the relationship between __len__
> and len(). Am I missing something that makes d.copy() preferable to copy(d)?
>
> I don't think we'll ever get another chance to clean-up the mapping API and to remove duplicate functionality (the code for
> dict.__copy__ and dict.copy share the same implementation).
I find the use of a copy operation that purports to copy any object
suspect (regardless whether it's a module or a builtin), and that I'd
rather have a copy() method on the MutableMapping API.
I think my objection against the fully generic copy operation is that
it's type is useless -- all we know that it is supposed to return the
same type as its argument, but our type system can't express that. The
type of the more constrained (but still generic in the sense of PEP
3124) copy operation on mutable sequences is better defined -- it
returns another mutable sequence, with the understanding that it
typically returns something of the same type as its input, though not
always -- e.g. if I subclass dict but don't override .copy(), the
inherited .copy() method returns a dict, not my subclass.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list