- Original message - I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) is...
Speaking of polymorphic, it seems like it would make sense to allow classes to specify their own __copy__ method for cases where specialized handling of copy is needed. copy.copy is sometimes overzealous, and therefore less efficient than necessary. Copy is a pretty fundamental idea, and I routinely run up against the fact that not only is there more than one way to do it (via constructors, using copy.copy, or when supported, thing.copy), the only "standard" approach requires an import and is weirdly one size fits all. Having a __copy__ slot and a builtin copy function with current copy.copy behavior as a fallback would be great. Just my accurately-valued 2 cents. - C Sent from Gmail for mobile On 2/9/08, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 07:51 PM 2/8/2008 -0500, Raymond Hettinger wrote: > >I recommend dropping the dict.copy() method from Py3.0. > > > >* We can already write: newd = copy.copy(d). > >* We can also write: newd = dict(d) > >* Both of those approaches also work for most other containers. > > I'm not fond of this idea. dict.copy() is polymorphic -- but dict(d) isn't. > > copy.copy() is polymorphic, but requires an import, which means the > path of least resistance will be to use dict(d)... which will then > turn non-dictionaries into dictionaries. > > If copy.copy() were a builtin and the "one obvious way" to copy > containers, +1. Otherwise, -0.5. > > _______________________________________________ > 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/shiblon%40gmail.com > -- Sent from Gmail for mobile | mobile.google.com _______________________________________________ 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
