[Python-Dev] Re: Re: lists v. tuples

[Alex Martelli]

On Monday 17 March 2003 02:50 am, Guido van Rossum wrote:
> > Guido:
> > > And I'm still hoping to remove __cmp__; there should be only one
> > > way to overload comparisons.
>
> [Greg]
>
> > I'd rather you kept it and re-defined it to mean
> > "compare for arbitrary ordering". (Maybe change its
> > name if there are backwards-compatibility issues.)
>
> Hm, that's not what it does now, and an arbitrary ordering is better
> defined by a "less" style operator.

+1.  I entirely agree that any ordering is easier to define with a
2-way comparison with the usual constraints of ordering, i.e.,
for any x, y, 
    before(x,x) is false, 
    before(x,y) implies not before(y,x), 
    before(x,y) and before(y,z) implies before(x,z)
and for this specific purpose of arbitrary ordering, it would, I think,
be necessary for 'before' to define a total ordering, i.e. the implied
equivalence being equality, i.e.
    not before(x,y) and not before(y,x) imply x==y
(This latter desideratum may be a source of problems, see below).

It would also be very nice if before(x,y) were the same as x<y
whenever the latter doesn't raise an exception, if feasible.


> I've been thinking of __before__ and a built-in before(x, y) -> bool.
> (Not __less__ / less, because IMO that's to close to __lt__ / <.)

I love the name 'before' and I entirely concur with your decision
to avoid the name 'less'.

> BTW, there are two possible uses for before(): it could be used to
> impose an arbitrary ordering for types that don't have one now (like
> complex); and it could be used to impose an ordering between different
> types (like numbers and strings).  I've got a gut feeling that the
> requirements for these are somewhat different, but can't quite
> pinpoint it.

Perhaps subclassing/subtyping [and other possible cases where
x==y may be true yet type(x) is not type(y)] may be the sticky
issues, when all desirable constraints are considered together.  

The simplest problematic case I can think of is before(1,1+0j) --
by the "respect ==" criterion I would want both this comparison,
and the same one with operands swapped, to be false; but by
the criterion of imposing ordering between different incomparable
types, I would like 'before' to range all instances of 'complex'
"together", either all before, or all after, "normal" (comparable)
numbers (ideally in a way that while arbitrary is repeatable over
different runs/platforms/Python releases -- mostly for ease of
teaching and explaining, rather than as a specific application need).


Alex