[Python-ideas] ordered dict

[Josiah Carlson]

"BJörn Lindqvist" <bjourne at gmail.com> wrote:
> On 4/21/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > "BJörn Lindqvist" <bjourne at gmail.com> wrote:
> > > On 4/21/07, Terry Reedy <tjreedy at 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