[Python-Dev] Keep default comparisons - or add a second set?

[Josiah Carlson]

Jim Fulton <jim at zope.com> wrote:
> 
> Jim Jewett wrote:
> > PEP 3000 now suggests that dropping default comparison has become more
> > than an idle what-if.
> > 
> > Unfortunately, one very common use case of comparisons is to get a
> > canonical order.  If the order is sensible, all the better, but that
> > is not strictly required.  One of Python's selling points (especially
> > compared to Java) is that getting a canonical order "just works", even
> > if the objects being sorted are not carefully homogenized by hand. 
> > Python itself relies on this when comparing same-length dictionaries.
> > 
> > There are times when a specific comparison doesn't make sense (date vs
> > a datetime that it includes), but these are corner cases best handled
> > by the specific class that understands the specific requirements --
> > classes that already have to override the comparison operators anyhow.
> > 
> > Even the recently posted "get rid of default comparisons" use case is
> > really just an argument to make the canonical ordering work better. 
> > The problem Jim Fulton describes is that the (current default)
> > canonical order will change if objects are saved to a database and
> > then imported to a different session.  Removing default comparisons
> > wouldn't really help much; the errors would (sometimes) show up at
> > saving instead of (maybe) at loading, but the solution would still be
> > to handcode a default comparison for every single class individually.
> 
> I think you need to do a much better job of defining canonical ordering.
> 
> You've given two properties:
> 
> - It need not make sense. :)
> 
> - It must be consistent accross sessions
> 
>    Does this also mean accross different versions of Python?
> 
>    How about different operating systems and hardware?
> 
>    If I create and pickle a BTree with a bunch of object keys
>    and reload that pickle in a different session, with a
>    later version of Python on a different OS and Hardware
>    architecture, will the keys still have the same order?
> 
>    I consider (obviously) this second property to be crucial.
> 
> Do you have any proposal for how to achieve these properties?

New superclasses for all built-in types (except for string and unicode,
which already subclass from basestring).

int, float, complex (long) : subclass from basenumber
tuple, list, set : subclass from basesequence
dict : subclass from basemapping

The idea is that each of the above classes define a group in which items
are comparable.  If you end up in a situation in which the base classes
of the compared object differ (and hence are not comparable directly by
value), you compare their base class name.  Because their base classes
differ, you always get a reliable differentiation between groups.


What about comparisons between user-defined classes (classic or subclass
of object)?  Presumably if a user wanted something to be compared
against integers, floats, or complex, the user would subclass from
basenumber, etc.  If the user only wanted their objects to compare
against objects of its own type, they compose their own __cmp__ or
related methods on their class, and they get this behavior 'for free'.

The only thing necessary for canonical ordering persistancy is that the
content of an object define its behavior in comparison operators, and
that pickle knows how to save and restore this content reliably.


Note that one can remove the superclass requirement with a smart cmp()
builtin to automatically choose the comparable group.


This is not perfect, but it is an idea, and it would allow a reliable
canonical ordering.

 - Josiah