cmp and sorting non-symmetric types

[Raymond Hettinger]

On Nov 13, 10:51 am, "Adam Olsen" <rha... at gmail.com> wrote:
> Although py3k raises an exception for completely unsortable types, it
> continues to silently do the wrong thing for non-symmetric types that
> overload comparison operator with special meanings.
> To solve this I propose a revived cmp (as per the previous thread[1]),
> which is the preferred path for orderings.  The rich comparison
> operators will be simple wrappers for cmp() (ensuring an exception is
> raised if they're not merely comparing for equality.)
>
> Thus, set would need 7 methods defined (6 rich comparisons plus
> __cmp__, although it could skip __eq__ and __ne__), whereas nearly all
> other types (int, list, etc) need only __cmp__.

Am strongly against this.  Please don't re-introduce an atrocity to
solve this non-problem. I realize that it bugs you but AFAICT it never
is an issue in real programs and I expect it to be even less likely in
Py3.0 where we get much farther away from sorts of hetrogenous types.
Also, sort() is no different than hash() or any other function that
can be fooled by a magic method implementation that doesn't do what
the calling function expects (for example, a custom __hash__ method
returning a random number will make it possible to add dict entries
that cannot be retrieved).

Also, keep in mind that cmp died for a reason.  Having it exist
alongside rich comparison operations was confusing for users and it
complicated the heck out of the CPython implementation (and checking
for it is slow)


Raymond