Changed in version 3.4: The __format__ method of$_{object}$itself raises a$_{TypeError}$ if passed any non- empty string. 

Changed in version 3.7: object.__format__(x, '') is now equivalent to str(x) rather than format(str(x), '') . 

object. __lt__ ( self , other ) object. __le__ ( self , other ) object. __eq__ ( self , other ) object. __ne__ ( self , other$_{)}$ object. __gt__ ( self , other ) object. __ge__ ( self , other ) 

These are the so-called “rich comparison” methods. The correspondence between operator symbols and method names is as follows: $_{x<y}$calls x.__lt__(y) , x<=y calls x.__le__(y) , x==y calls x. __eq__(y) ,$_{x!=y}$ calls$_{x.__ne__(y)}$ ,$_{x>y}$calls$_{x.__gt__(y)}$ , and$_{x>=y}$ calls$_{x.__ge__(y)}$ . 

A rich comparison method may return the singleton$_{NotImplemented}$if it does not implement the operation for a given pair of arguments. By convention, False and True are returned for a successful comparison. However, these methods can return any value, so if the comparison operator is used in a Boolean context (e.g., in the condition of an$_{if}$ statement), Python will call$_{bool()}$ on the value to determine if the result is true or false. 

By default, object implements __eq__() by using is , returning NotImplemented in the case of a false comparison: True if x is y else NotImplemented . For$_{__ne__()}$ , by default it dele- gates to$_{__eq__()}$ and inverts the result unless it is$_{NotImplemented}$ . There are no other implied re- lationships among the comparison operators or default implementations; for example, the truth of$_{(x<y or}$ x==y) does not imply$_{x<=y}$ . To automatically generate ordering operations from a single root operation, see functools.total_ordering() . 

See the paragraph on$_{__hash__()}$ for some important notes on creating hashable objects which support custom comparison operations and are usable as dictionary keys. 

There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather,$_{__lt__()}$ and$_{__gt__()}$ are each other’s reflection, __le__() and$_{__ge__()}$ are each other’s reflection, and$_{__eq__()}$ and$_{__ne__()}$ are their own re- flection. If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority. Virtual subclassing is not considered. 

## object. __hash__ ( self$_{)}$ 

Called by built-in function$_{hash()}$and for operations on members of hashed collections including$_{set}$, $_{frozenset}$, and$_{dict}$ .$_{__hash__()}$ should return an integer. The only required property is that objects which compare equal have the same hash value; it is advised to mix together the hash values of the components of the object that also play a part in comparison of objects by packing them into a tuple and hashing the tuple. Example: 

def __hash__(self): return hash (( self.name,self.nick,self.color)) 

Note: $_{hash()}$truncates the value returned from an object’s custom$_{__hash__()}$ method to the size of a$_{Py_ssize_t}$. This is typically 8 bytes on 64-bit builds and 4 bytes on 32-bit builds. If an object’s __hash__() must interoperate on builds of different bit sizes, be sure to check the width on all sup- ported builds. An easy way to do this is with$_{python -c "import sys; print(sys.hash_info.}$ width)" . 

If a class does not define an$_{__eq__()}$ method it should not define a$_{__hash__()}$ operation either; if it defines$_{__eq__()}$ but not$_{__hash__()}$ , its instances will not be usable as items in hashable collections. If a class defines mutable objects and implements an$_{__eq__()}$ method, it should not implement$_{__hash__()}$ , since the implementation of hashable collections requires that a key’s hash value is immutable (if the object’s hash value changes, it will be in the wrong hash bucket). 

