"BJörn Lindqvist" <bjourne@gmail.com> wrote:
On 4/21/07, Josiah Carlson <jcarlson@uci.edu> wrote:
"BJörn Lindqvist" <bjourne@gmail.com> wrote:
On 4/21/07, Terry Reedy <tjreedy@udel.edu> wrote:
But it *is* currently a problem for lists that will become much more extensive in the future, so it *is* currently a problem for sorted dicts that will be much more of a problem in the future. Hence, sorted dicts will have to be restricted to one type or one group of truly comparable types.
Alternatively, you could require a comparator function to be specified at creation time.
You could, but that would imply a total ordering on elements that Python itself is removing because it doesn't make any sense. Including a list of 'acceptable' classes as Terry has suggested would work, but would generally be superfluous. The moment a user first added an object to the sorted dictionary is the moment the type of objects that can be inserted is easily limited (hello Abstract Base Classes PEP!)
Where did the "we are all consenting adults here" mantra go? Java doesn't imply any total order on elements either, yet it manages to fit a TreeMap class that does not artificially limit the kind of items you can put in it. Yes, you can "screw up" by overriding the hashCode and equals methods of the items you put in it. Java, in this case, doesn't try to enforce correctness on the language level, instead it documents the contract the programmer is supposed to follow. m1.equals(m2) should imply that m1.hashCode() == m2.hashCode().
At no point has there been discussion over removing the ability for types which don't have a total ordering to be placed into a dictionary (hash table). a = {1:2, None:6, 'hello':0} will always work. The only thing that anyone has talked about is the removal of >, >=, <, <= for types that make no sense to compare. Like unicode and tuple, or int and tuple, or int and list, etc. The removal of a "total ordering" does not imply that 5 != 'hello' will somehow start failing, it means that 5 < 'hello' will begin to raise an exception because it doesn't make any sense.
Similar fuck ups are possible when using dicts. In practice this is not a problem. An ordered dict doesn't need any more safeguards than Python's already existing data structures. Using the natural order of its items are just fine and when you need something more fancy, override the __eq__ method or give the collections sort method a comparator function argument.
Except this series of posts is about a "sorted dict", with a key,value mapping in which the equivalent .items() are sorted() as an ordering (rather than more or less dependant on hash value as in a standard dictionary). But as I, and others have stated before, which you should read once again because you don't seem to get it: THE EXISTANCE OF A TOTAL ORDERING ON VALUES IN PYTHON TODAY IS A LIE. IN FUTURE PYTHONS WE ARE REMOVING THE LIE BECAUSE IT DOESN'T HELP ANYONE. IF YOU DON'T LIKE IT; TOUGH COOKIES. STANDARD PYTHON DICTIONARIES WILL WORK THE WAY THEY ALWAYS HAVE. ONLY PEOPLE WHO BELIEVE THAT INCOMPATIBLE TYPES SHOULD BE ORDERED IN A PARTICULAR WAY IN THINGS LIKE lst.sort() WILL BE AFFECTED. If you want an actual reference, please see PEP 3100 which says, "Comparisons other than == and != between disparate types will raise an exception unless explicitly supported by the type" ... and references: http://mail.python.org/pipermail/python-dev/2004-June/045111.html If you don't understand this, please ask again without profanity or accusing the Python developers of removing the "consenting adults" requirement. Python is getting smarter. Maybe you just don't understand why this is the case. - Josiah