[Python-3000] Nix dict.copy()
Guido van Rossum
guido at python.org
Tue Feb 12 23:52:04 CET 2008
On Feb 12, 2008 2:40 PM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> > Based on the same reasoning, when
we see x = copy(y) we can tentatively
> assume that y is a type that can usefully be copied. Unless we don't trust
> the author of the code to be sensible.
My point is that (almost) any type is copyable so we can't tell what
the author is assuming. Maybe they believe they had either a list or a
dict -- or maybe they know they have an arbitrary class instance.
> > Seeing x=copy(y) provides no new information about y, since
> > all (well, most) objects can be copied. OTOH seeing x=y.copy() *does*
> > provide new information about y; it must be a type that has a .copy()
> > method.
> What useful information do we get by knowing that a type has a .copy()
It rules out all classes that don't have one. That's nearly all types.
> If I took the last sentence out of context, I would assume that having a
> .copy() method informs you that the type is copyable. Except you've just
> said that all (well, most) objects in Python can be copied--so I'm not sure
> new information a .copy() method conveys.
Only dict and a few mapping-like types (and a vanishingly small number
of user-defined classes) define copy().
> Normally I might assume that it does a special kind of copying that doesn't
> fit the definition of copy.copy() nor copy.deepcopy(), except that for dict
> and set types, .copy() and .__copy__() are identical.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000