On Feb 11, 2008 7:58 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
