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

[M.-A. Lemburg]

Josiah Carlson wrote:
> 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

set should be under 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.

Python already uses this "trick" based on the type name.
If that still doesn't help, id(object) is used which is
what JimF is criticizing (I presume).

> 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. 

... and get all kinds of weird side-effects. A user
probably doesn't want these :-)

> 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.

Actually, the only thing necessary for *persisting* order is
making sure that the persistence logic maintains order across
pickling.

Note that this is a completely different requirement
than making sure that the outcome of list.sort() is the same
across platforms and sessions.

> 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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 20 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::