RetroSearch Browse

Thu Dec 29 00:43:38 CET 2005 · http://mail.python.org/pipermail/python-dev/2005-December/059232.html

Noam Raphael wrote:
> Perhaps it bothers the programmer with something that shouldn't bother
> him. I mean that I might do help(set.copy), and then think, "Oh, it
> returns a shallow copy. Wait a minute - 'shallow' means that I get a
> new object, which references the same objects as the old one. Perhaps
> I should use another function, which does deep copying? Let me think
> about it - no. All members of a set are immutable, so it doesn't
> matter." I think that in this case, the fact that the copy is shallow
> is an implementation detail, since there's no sense in making a deep
> copy of a set.

If "makes no sense" means "would not make a difference", then you
are wrong. Objects in a set are not necessarily unmodifiable;
they just have to be hashable. Watch this:

>>> class A:
...   def __hash__(self):return 0
...   def __cmp__(self, other):return 0
...
>>> a1 = A()
>>> import copy
>>> a2 = copy.deepcopy(a1)
>>> a1.x = 10
>>> a2.x = 20
>>> a1.x
10
>>> s = set([a1])
>>> a2 in s
True

So even though a1 and a2 are distinct objects with different, modifiable
state, they are treated as equal in the set. A deepcopy of the set (if
it existed) would do something different than a plain copy.

> I know it's just a word, and that it doesn't matter a lot. But why not
> make things a tiny bit better?

Things would get worse. The code would become underspecified.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-December/059232.html below:

[Python-Dev] set.copy documentation string