[Python-bugs-list] [ python-Bugs-663701 ] sets module review
SourceForge.net
noreply@sourceforge.net
Sun, 12 Jan 2003 21:28:01 -0800
Bugs item #663701, was opened at 2003-01-07 09:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien Keim (s_keim)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: sets module review
Initial Comment:
* 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?
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2003-01-13 00:28
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-12 09:28
Message:
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.
----------------------------------------------------------------------
Comment By: Terry J. Reedy (tjreedy)
Date: 2003-01-07 17:44
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470