cmp() fallback to rich comparison operators

[GoogleCodeExporter]

implement the sort semantics of class obj through the __lt__ method.
It's quite common to sort complex obj list

test case:

class inst(object):
    def __init__(self, num, opcode='add', pc='1'):
        self.opcode = opcode
        self.pc = pc
        self.num = num

    def __lt__( self, other):
        return self.num < other.num

    def __repr__(self): 
        return "%d" % self.num

Seq = [inst(3),inst(1),inst(4),inst(2)]
print Seq
print sorted(Seq)

Python output:
[3, 1, 4, 2]
[1, 2, 3, 4]

Original issue reported on code.google.com by jason.mi...@gmail.com on 16 Jul 2011 at 8:26

[GoogleCodeExporter]

The sort routines are guaranteed to use __lt__() when making comparisons 
between two objects. So, it is easy to add a standard sort order to a class by 
defining an __lt__() method

Original comment by jason.mi...@gmail.com on 16 Jul 2011 at 8:46

[GoogleCodeExporter]

Issue 148 has been merged into this issue.

Original comment by mark.duf...@gmail.com on 16 Jul 2011 at 10:49

[GoogleCodeExporter]

Original comment by mark.duf...@gmail.com on 16 Jul 2011 at 11:01

• Changed state: Accepted
• Added labels: milestone-0.9

[GoogleCodeExporter]

thanks ;)

this one is a bit tricky to support at the moment. I'm thinking about how to 
(efficiently) match cpython here, but haven't found an elegant solution yet. 
the following is a work-around in any case. btw, I really don't like the rich 
comparison operators such as __lt__, since they seem overkill in almost any 
situation. 

def __cmp__(self, other):
    return cmp(self.num, other.num)

I'm leaving the issue open until I finish investigating this further.. :) 
thanks again!

Original comment by mark.duf...@gmail.com on 16 Jul 2011 at 1:03

• Changed title: cmp() fallback to rich comparison operators

[GoogleCodeExporter]

Yes, __cmp__ is a doable work-around

FYI
Looks  like  __cmp__ will be obsoleted in PY3:

In Py3.0, the cmp parameter was removed entirely (as part of a larger effort to 
simplify and unify the language, eliminating the conflict between rich 
comparisons and the __cmp__() magic method)
http://docs.python.org/howto/sorting.html

Original comment by jason.mi...@gmail.com on 17 Jul 2011 at 12:36

[GoogleCodeExporter]

alright, this one works in GIT now.. I had to find something that looks like a 
'hasattr' implementation for C++ to solve this.. since shedskin sorting 
currently calls 'cmp' by default, I changed 'cmp' for now to do a 
'hasattr(__cmp__)', and use __eq__ and __lt__ if __cmp__ is not there. I will 
leave the issue open until I've nailed all similar cases for comparison and 
sorting. thanks again for triggering!

interestingly, using 'cmp' for instances of this class is now actually 
faster..! (the C++ 'hasattr' stuff is all evaluated at compile-time, but I 
measured just to be sure..)

yeah, cmp will disappear. I guess it does clean up some redundancy.. 

Original comment by mark.duf...@gmail.com on 17 Jul 2011 at 4:58

• Changed state: Started

[GoogleCodeExporter]

mrwh, I wasn't completely happy with my changes, so I reverted them for now.. 
please use the workaround for now. I will think a bit about this over the next 
few weeks.. hopefully by 0.9 this is generally fixed.

Original comment by mark.duf...@gmail.com on 18 Jul 2011 at 8:18

[GoogleCodeExporter]

I fixed this case in a less invasive way just now, so the program above should 
work again.. :-)

Original comment by mark.duf...@gmail.com on 18 Jul 2011 at 7:24

[GoogleCodeExporter]

Original comment by mark.duf...@gmail.com on 30 Jul 2011 at 12:29

• Changed state: Fixed