* the ^ operator doesnt print well in pdf generated
documentation (both in what's new and in library reference)

* shouldn't the _as_immutable and
_as_temporaly_immutable be spelled __as_immutable__ and
__as_temporaly_immutable__ for consistency with other
hook methods?

* cmp() suck:
<pre>
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> s = sets.Set
>>> a = s([0])
>>> b = s([1])
>>> cmp(a,b)
1
>>> 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> a=sets.Set([0])
>>> b=sets.Set([1])
>>> cmp(a,b)
-1
</pre>

* Because we can have set1!=set2 and both
(set1<set2)==False and (set2<set1)==False what will be
the behavhior of: [set1, set2].sort().
Since inclusion can't  define a full ordering relation,
wouldn't it be better to remove the equivalence between
issubset and __lt__ (and other comparaison methods) and
to use an equivalent to the dictionary protocol to
define the < and > behavior?

Logged In: YES 
user_id=593130

If/when sets become builtin, would type object be 
called 'set' or break current convention by being 
called 'Set'?  If the former, I think classSet should be 'set' 
now so one can write 'from sets import set' and have rest 
of code ready for the future.

Logged In: YES 
user_id=6380

It's unlikely that the built-in type will behave exactly the
same, so the name difference is a good way to distinguish
the module from a future builtin.

Regarding cmp(): hmm, we may need to think about this more.
Currently comparison operators are used to express subset
relationships, e.g. <= means subset, < means strict subset.
The result of this is that cmp() between sets that are
neither subset nor set gets a useless outcome. (I can
reproduce your example but can't explain it.) Maybe we
should implement __cmp__ to raise an exception? Or maybe <=
for subset is too cute?

Assigning for Tim to ask his opinion.

Logged In: YES 
user_id=31435

try_rich_to_3way_compare gives up after LT, EQ and GT all 
return false.  The comparison then falls back to the default 
comparison by object id (addresses).  So, e.g., I can build 
an a, b, and c on my box such that:

>>> a, b, c
(Set([0]), Set([1]), Set([1]))
>>> cmp(b, c)   # b equals c
0
>>> cmp(a, b)   # but a "greater than" b while
1
>>> cmp(a, c)   # a "less than" c, despite that b == c
-1
>>>

This is simply because a is at a lower address than c but at 
a higher address than b:

>>> id(a) < id(c)
True
>>> id(a) > id(b)
True
>>>

I don't think <= for subset is too cute -- sets do have a 
natural and useful partial order.  I don't really care happens 
if you pass them to cmp(), though.  An exception would be 
fine -- sets weren't intended to be "generally" comparable.

Logged In: YES 
user_id=6380

Assigning to Raymond Hettinger. Maybe there are some
concrete to-do items above; after that I think it can be
closed. Maybe using __xxxx__ names is a good idea (since
when somebody else reuses these names, we can blame it on
them violating the rule not to use __xxxx__ names except as
documented).

Logged In: YES 
user_id=80475

Done.
Committed as:  Lib/sets.py 1.41 and 1.42
                          Doc/lib/libsets.tex 1.11