[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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
