Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > cmp and sorting non-symmetric types

Reply
Thread Tools

cmp and sorting non-symmetric types

 
 
Adam Olsen
Guest
Posts: n/a
 
      11-13-2007
(I've had trouble getting response for collaboration on a PEP.
Perhaps I'm the only interested party?)

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.

>>> a = set([1])
>>> b = set([2, 5])
>>> c = set([1, 2])
>>> sorted([a, c, b])

[{1}, {1, 2}, {2, 5}]
>>> sorted([a, b, c])

[{1}, {2, 5}, {1, 2}]

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

Code which uses <= to compare sets would be assumed to want subset
operations. Generic containers should use cmp() exclusively.


[1] http://mail.python.org/pipermail/pyt...er/011072.html

--
Adam Olsen, aka Rhamphoryncus
 
Reply With Quote
 
 
 
 
Raymond Hettinger
Guest
Posts: n/a
 
      11-13-2007
On Nov 13, 10:51 am, "Adam Olsen" <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      11-13-2007
On Nov 13, 1:51 pm, "Adam Olsen" <(E-Mail Removed)> wrote:
> (I've had trouble getting response for collaboration on a PEP.
> Perhaps I'm the only interested party?)
>
> 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.
>
> >>> a = set([1])
> >>> b = set([2, 5])
> >>> c = set([1, 2])
> >>> sorted([a, c, b])

>
> [{1}, {1, 2}, {2, 5}]>>> sorted([a, b, c])
>
> [{1}, {2, 5}, {1, 2}]
>
> 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__.
>
> Code which uses <= to compare sets would be assumed to want subset
> operations. Generic containers should use cmp() exclusively.



I second Raymond Hettinger's strong -1 on this.

I would further suggest that it's the wrong solution even insofar as
it's a problem. The right solution is to use comparison operators
only for ordered comparisons, not for subset and superset testing.
Unfortunately, the rogue operators are already there and in use, so
the right solution would probably cause more trouble than it would
save at this point. But it'd still cause less trouble than
resurrecting the __cmp__ operator.


Carl Banks

 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      11-13-2007
Carl Banks <(E-Mail Removed)>
> resurrecting the __cmp__ operator.


I didnd't realize __cmp__ was going. Are we really supposed to
implement all the rich comparison methods to code an ordered class?
Or is there some kind of library superclass we can inherit from that
implements something like __cmp__? What about making __key__ ?
 
Reply With Quote
 
Raymond Hettinger
Guest
Posts: n/a
 
      11-14-2007
On Nov 13, 1:18 pm, Carl Banks <(E-Mail Removed)> wrote:
> The right solution is to use comparison operators
> only for ordered comparisons, not for subset and superset testing.


The whole point of the rich comparisons PEP was to be able to override
the operators for other purposes.



Raymond

 
Reply With Quote
 
Raymond Hettinger
Guest
Posts: n/a
 
      11-14-2007
On Nov 13, 2:54 pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> Carl Banks <(E-Mail Removed)>
>
> > resurrecting the __cmp__ operator.

>
> I didnd't realize __cmp__ was going. Are we really supposed to
> implement all the rich comparison methods to code an ordered class?
> Or is there some kind of library superclass we can inherit from that
> implements something like __cmp__? What about making __key__ ?


IIRC, you need only define __le__ and __eq__ and the rest get defined
using a mixin class.


Raymond

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Argument type of function and safe types and types, arguments canhandle safely ittium C++ 4 12-09-2011 11:05 AM
Python3: sorting image objects according to a cmp function Poor Yorick Python 0 12-03-2008 02:06 PM
Replacing cmp with key for sorting George Sakkis Python 8 11-03-2008 09:40 PM
no cmp field defined in cmp ejb Andrea Sansottera Java 0 07-16-2004 02:24 PM
CMR/CMP and Compound Primary Key Damir Mikoc Java 1 07-04-2003 03:27 AM



Advertisments