PEP 218 Re: ANN: set-0.1 module available

[Bengt Richter]

On 18 May 2002 17:15:29 +0200, Bernhard Herzog <bh at intevation.de> wrote:

>Erik Max Francis <max at alcyone.com> writes:
>
>> That's not the half of it.  Mutable objects can dynamically change
>> state, completely outside the control of the container.  So the hard
>> question is:  What happens when a mutable object changes its value, such
>> that it effects the arrangement of the set?  How does the container get
>> notified of this change (which as far as I know there is no standard way
>> to test in Python), and what happens when a value collision occurs
>> within the set?  Does one object get disposed?  If so, which one?
>
Perhaps there could be a const-on-hash (mark as immutable if ref counts==1,
copy and mark otherwise), and then copy-on-write (copy if const, un-const the copy,
and proceed with mutating operation on the copy), so sets could play both
roles. This would just be an optimization for some kinds of sets, but probably
wouldn't be worth it for e.g., small sets of bits that could be implemented as
packed into 32-bit integers. In any case, it w/shouldn't change the set semantics.

>It seems to me that the most sensible solution would be to deal with it
>like a dictionary deals with mutable keys: By not caring about whether
>an object is mutable or not (there is no way to determine this anyway)
>but relying on a certain behavior regarding hash values instead.

 >>> d={}
 >>> l=range(5)
 >>> d[l]='list5'
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 TypeError: list objects are unhashable
 >>> l2=tuple([[x] for x in xrange(5)])
 >>> l2
 ([0], [1], [2], [3], [4])
 >>> d[l2] = 'tuplist5'
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 TypeError: list objects are unhashable

It seems to care "about whether an object is mutable or not" and doesn't
seem to believe that "(there is no way to determine this anyway)".

You must have meant something else?

>
>If an object is stored in a dict as a key, the only things that matter
>are that
>
>1. its hash value doesn't change as long as the object is used as a key.
>
>2. equal objects have equal hash values
>
for some definition of hashing an object equality...

>There may be some more subtle requirements. I'm not sure what happens
>when two objects that have the same hash value but do not compare eqal
>at first later become equal, for instance.
>
You're not confusing names and values, are you?

Regards,
Bengt Richter