[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