[Python-3000] Nix dict.copy()

Raymond Hettinger python at rcn.com
Sun Feb 10 23:14:51 CET 2008


[Martin]
> So indeed, your claim that .copy "is [not]
> really polymorphic" is quite puzzling - we now seem to agree that it
> *is* polymorphic.

Yes, of course.  Every method used by dict imitators could be considered polymophic.  I was just observing copy.copy(obj) applies to 
many, many more object types than obj.copy().

The former works with lists, tuples, deques, strings, and all kinds of things.  The latter shows-up mainly in dict imitators.


> So going back to your original message, you should remove dict(d)
> from the list of alternatives for dict.copy() (or remark that this
> will be a copy-to-basetype, so not quite the same thing).

That makes sense.  You can never be sure of a constructor's signature.  It works most of the time but not all of the time.


>> Had copy() been a builtin, we probably wouldn't be having this discussion.
>
> Interestingly enough, dict.copy was added *after* copy.copy (in r8135),
> which supported __copy__ right from the beginning (since r4555). Even
> more interesting, it was added along with dict.absorb, which then
> got renamed dict.update a week later. No rationale is given in the
> checkin message on the purpose of the copy method.

Interesting history.

Now, we have one and only one chance to slim-down the mapping API, leaving the copy() function as the one, universal, preferred way 
to do it.  I don't think this chance will come again.


Raymond 


More information about the Python-3000 mailing list