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), '') . 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: 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). Chapter 3. Data model 28 def __hash__(self): return hash (( self.name,self.nick,self.color)) object. __lt__ ( self , other ) object. __le__ ( self , other ) object. __eq__ ( self , other ) object. __ne__ ( self , other$_{)}$ object. __gt__ ( self , other ) object. __ge__ ( self , other ) The Python Language Reference, Release 3.9.5