Python3: why the comparison is naturally made? - python-3.x

Question

In the code below, I defined '<' in the magic method __lt__(), which will return True if the first argument is less than the second one, return False otherwise.
from functools import total_ordering
#total_ordering
class Currency:
"""
One object of class Currency stores one amount of money, dollars and cents.
"""
def __add__(self, other):
"""
returns the result of adding self to other
"""
total = Currency(self.dollars, self.cents)
total.dollars = total.dollars + other.dollars
print (other.dollars)
total.cents = total.cents + other.cents
print (other.cents)
if total.cents > 100:
total.cents = total.cents - 100
total.dollars = total.dollars +1
return total
def __init__(self, dollars=0, cents=0):
self.dollars = dollars
self.cents = cents
def __str__(self):
return "$"+str(self.dollars)+"."+str(self.cents)
def __eq__(self, other):
return self.dollars==other.dollars and self.cents==other.cents
def __lt__(self, other):
if self.dollars<other.dollars:
return True
elif self.dollars > other.dollars:
return False
else: # dollars are equal
return self.cents < other.cents
And then I called __lt__() in the test program with '<'. In this case, the candyPrice(first argument) is less than bookPrice(second argument), so it returned True as expected. And then, I compared these two values with '>' which was not predefined in class Currency, but it also returned False as expected. So I'm wondering if it's because __lt__() was defined already, then the opposite expression, the '>' expression, was also implicitly defined?
if __name__ == "__main__":
candyPrice = Currency (1, 17) # $1.17
bookPrice = Currency (12, 99) # $12.99
print (candyPrice < bookPrice)
print (candyPrice > bookPrice)

Answer 1

You used the #total_ordering class decorator. This decorator explicitly adds the other methods for you.
From the #functools.total_ordering documentation:
Given a class defining one or more rich comparison ordering methods, this class decorator supplies the rest. This simplifies the effort involved in specifying all of the possible rich comparison operations:
The class must define one of __lt__(), __le__(), __gt__(), or __ge__(). In addition, the class should supply an __eq__() method.
So even though you did not define a __gt__ method, the class decorator has defined one for you using your __lt__ method, together with __eq__.
For example, when defining a __lt__ method, the __gt__() implementation is set to:
def _gt_from_lt(self, other, NotImplemented=NotImplemented):
'Return a > b. Computed by #total_ordering from (not a < b) and (a != b).'
op_result = self.__lt__(other)
if op_result is NotImplemented:
return op_result
return not op_result and self != other
So if self < other is false, self != other is used. You did not define a __ne__ method, but you did provide a __eq__ and the default for __ne__ is then to return not self.__eq__(other); see the object.__ne__() documentation:
By default, __ne__() delegates to __eq__() and inverts the result unless it is NotImplemented.
For your test Currency instances __eq__ is not needed, candyPrice.__gt__(bookPrice) calls candyPrice.__lt__(bookPrice), which returns true and thus False is returned without checking for self != other.