Guido van Rossum wrote: >> >> The deeper problem is that decisions on which values to keep will >> inevitability break set invariants (see a long list of these in >> test.test_set.py): >> >> assert a|b == b|a, 'commutative property' >> assert (a-b) | (a&b) | (b-a) == a|b, 'whole is the sum of the parts' > > > Yeah, I think when I was cosidering this earlier (it's been a shower > thought for quite a while on and off) I considered those fatal flaws. > Today, I think the invariants would simply change to > > assert set(a|b) == set(b|a) == set(a)|set(b) == set(b)|set(a) > > with set() being an alias for dict.fromkeys().
The outermost set coercion is not especially attractive or efficient. Since equality/inequality is an important set operation, we would likely need to add a method for equality testing that ignores dict values: d1.compareKeys(d2) # equivalent to: set(d1)==set(d2) The frozenset type also needs to be addressed. They don't come-up much in practice but when they do, they are vital to the solution, so some kind of frozenset type should be kept around (perhaps in the collections module). However, I have long argued against having frozendicts and I want to kill THAT discussion before it rears its ugly head again. I'm curious as to whether people will find one-type-with-two-purposes easier to learn that what we have now. My experience so far is that sets have a near zero learning curve as they are currently implemented. Also, I wonder whether it is wise to place any further burden on either the mapping API or its implementation (do we want weakref dictionaries and dbm's supporting set ops?). Raymond _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
