>>>> I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) >>>> is... > > [Raymond] >>> Can't say dict.copy() is really polymorphic if only one other class >>> defines the method. > > [Martin] >> Why do you say it's only one? I found atleast UserDict.copy, >> os._Environ.copy, WeakValueDictionary.copy, WeakKeyDictionary.copy, > > It would have been better for me to say that copy() seems to appear only > in variants of dicts, but __copy__() is a long-standing defined protocol > that is supported across non-mapping types as well.
But that's Phillip's point: dict(d) is not polymorphic, yet d.copy() is. That's important in applications where you want to copy a dict-like object polymorphically. So indeed, your claim that .copy "is [not] really polymorphic" is quite puzzling - we now seem to agree that it *is* polymorphic. 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). > 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. Regards, Martin _______________________________________________ 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
