Raymond Hettinger wrote: > There would be some implementation consequences in terms of speed and > memory usage (we would lose the memory savings and some of the speed-ups > gained in the Py2.5 implementation of sets).
Is that really necessary? Couldn't the keys and values be kept in separate arrays, and only allocate the values array the first time a non-canonical value is inserted? > Guido listed the basic conflicts 1) arbitrary decisions as to which > values to keep, 2) unexpected stings from != and == taking values into > account, 3) operations that don't make sense (__setitem__, setdefault, > etc). > ... > assert a|b == b|a, 'commutative property' > assert (a-b) | (a&b) | (b-a) == a|b, 'whole is the sum of the parts' These could be resolved by refusing to carry out set operations on a dict which contains non-canonical values. On the other hand, this mightn't really be much of a problem. These invariants will still be true of set-dicts which are being used as sets, i.e. contain only canonical values. And as you say, extending them to non-set dicts could have uses. Another way of thinking about this is that there are really two conceptual types, sets and dicts, which just happen to be implemented by the same concrete type. I don't think that's any worse than e.g. using a list to implement a stack or queue. As long as you use it as per the conceptual type you're thinking of, all the relevant invariants hold. -- Greg _______________________________________________ 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
