Which dunder methods matter most and what contracts do they carry?

Dunder methods are looked up on the type, not the instance, which is why special method behaviour is consistent for built-ins. Implementing them lets your objects work with len, ==, iteration, indexing, arithmetic, context managers and the with statement.

class Money:
    def __init__(self, cents, currency="USD"):
        self.cents = cents
        self.currency = currency

    def __repr__(self):
        return "Money(" + str(self.cents) + ", " + self.currency + ")"

    def __eq__(self, other):
        if not isinstance(other, Money):
            return NotImplemented
        return (self.cents, self.currency) == (other.cents, other.currency)

    def __hash__(self):
        return hash((self.cents, self.currency))

    def __add__(self, other):
        if self.currency != other.currency:
            raise ValueError("currency mismatch")
        return Money(self.cents + other.cents, self.currency)

print(Money(500) + Money(250))

Contracts to respect

• __repr__ should be unambiguous and ideally evaluable; __str__ is for users
• If you define __eq__, define __hash__ too or the object becomes unhashable
• Equal objects must have equal hashes, or dict and set behaviour breaks
• __getitem__ should raise IndexError for out-of-range access so iteration works

Do not overload operators with surprising meanings. A __add__ that mutates one operand or performs I/O will confuse anyone reading the call site. When in doubt, a named method communicates intent better than an operator.