As per python-dev discussion on Sat 13 July 2002, 
subject
"Dict constructor".  A version of Greg Wilson's sandbox
Set class that avoids the trickiness of implicitly freezing
a set when __hash__ is called on it.  Rather, uses 
several classes: Set itself has no __hash__ and 
represents a
general, mutable set; BaseSet, its superclass, has all
functionality common to mutable and immutable sets; 
ImmutableSet also subclasses BaseSet and adds 
__hash__; a wrapper _TemporarilyImmutableSet wraps
a Set exposing only __hash__ (identical to that an 
ImmutableSet built from the Set would have) and __eq__ 
and __ne__ (delegated to the Set instance).

Set.add(self, x) attempts to call x=x._asImmutable() (if
AttributeError leaves x alone); Set._asImmutable(self)
returns ImmutableSet(self).
Membership test BaseSet.__contains__(self, x) attempt
to call x = x._asTemporarilyImmutable() (if AttributeError 
leaves x alone); Set._asTemporarilyImmutable(self) 
returns TemporarilyImmutableSet(self).

I've left Greg's code mostly alone otherwise except for
fixing bugs/obsolescent usage (e.g. dictionary rather than
dict) and making what were ValueError into TypeError 
(ValueError was doubtful earlier, is untenable now that
mutable and immutable sets are different types).  The
change in exceptions forced me to change the unit tests
in test_set.py, too, but I made no other changes nor
additions.

Logged In: YES 
user_id=60314

Changed as per GvR comments so now sets have-a dict rather 
than being-a dict.  Made code more direct in some places (using
list comprehensions rather than loops where appropriate).

Logged In: YES 
user_id=6380

Thanks, Alex!

I've checked in a major rewrite of this in
<python>/nondist/sandbox/sets/set.py, replacing of Greg V.
Wilson's version.

Logged In: YES 
user_id=86307

I wonder if the binary operators perhaps should be changed to 
allow other to be a sequence (or really, anything iterable).  
That is, if other is not a set type, try to create an 
ImmutableSet using other and, if successful, use that for the 
operation. Of course, the conversion of iterable to set can be 
done explicitly by the code which uses the set operation, but 
it might be desirable to make this conversion implicit (under 
the "be generous in what you accept" principle).
 

Logged In: YES 
user_id=31435

-1 on that, Greg.  If Python sees

    list + set

it's got no more reason to believe that the programmer 
intended the list elements to be inserted into the set than 
to believe the intent was to append the set elements to the 
list.  "Be generous in what you accept" comes from the 
networking world, where the chances are good that the 
program on the other end was written by people who can't 
code confused by an ambiguous spec written by people 
who can't write <0.9 wink>.

Logged In: YES 
user_id=6380

I concur with TIm on that one, even though the set union
operator is |, not +.

In general, Python's container types don't mix in operations
that much -- you can't even concatenate a list to a tuple,
so we're already being generous by allowing Set and
ImmutableSet to mix.

Logged In: YES 
user_id=6380

Closing this. My latest version is checked into the standard
library now.