The data model — dunder methods

Python's operators and built-in functions do not know about your class. They call special methods ("dunder" methods, for the double underscores) that your class may define:

Implementing the right ones is what makes an object feel built in.

repr, str, and equality

__repr__ is for developers: unambiguous, ideally the expression that rebuilds the object. __str__ is for display and falls back to __repr__ when missing. Containers always show their elements' repr, which is why a list of objects without one prints memory addresses.

The default __eq__ is identity: two separately built objects are never equal, whatever they hold. Once you define __eq__, Python sets __hash__ to None, so the class becomes unhashable — it can no longer be a dict key or a set member — until you write a matching __hash__. The contract is one line: objects that compare equal must have equal hashes. Hash the same fields __eq__ compares, and only fields that never change after construction.

1class Plain:2    def __init__(self, x):3        self.x = x4 5 6class Point:7    def __init__(self, x, y):8        self.x, self.y = x, y9 10    def __repr__(self):11        return f"Point({self.x}, {self.y})"12 13    def __eq__(self, other):14        if not isinstance(other, Point):15            return NotImplemented16        return (self.x, self.y) == (other.x, other.y)17 18 19def run():20    p, q = Point(1, 2), Point(1, 2)21    try:22        hash(p)23        hashing = "hashable"24    except TypeError as e:25        hashing = f"TypeError: {e}"26    return {27        "plain_equal": Plain(1) == Plain(1),28        "point_equal": p == q,29        "point_is": p is q,30        "point_vs_tuple": p == (1, 2),31        "str_of_list": str([p, q]),32        "hash": hashing,33    }

NotImplemented, and the reflected operand

When __eq__ or __add__ receives a type it does not understand, it should return NotImplemented (a built-in constant, not an exception). Python then asks the other operand: b.__radd__(a) for +, b.__eq__(a) for ==. If both decline, == falls back to identity and + raises TypeError. Returning False instead would silently cut that second chance off.

sum() starts from 0, so its first step is 0 + first_item: the int declines, and only a __radd__ on your class can make it work.

1class Money:2    def __init__(self, cents):3        self.cents = cents4 5    def __repr__(self):6        return f"Money({self.cents})"7 8    def __add__(self, other):9        if isinstance(other, Money):10            return Money(self.cents + other.cents)11        return NotImplemented12 13    def __radd__(self, other):14        if other == 0:  # sum() starts from 015            return self16        return NotImplemented17 18 19class NoRadd:20    def __init__(self, cents):21        self.cents = cents22 23    def __add__(self, other):  # same __add__, but no __radd__24        if isinstance(other, NoRadd):25            return NoRadd(self.cents + other.cents)26        return NotImplemented27 28 29def attempt(fn):30    try:31        return repr(fn())32    except TypeError as e:33        return f"TypeError: {e}"34 35 36def run():37    return {38        "sum_money": attempt(lambda: sum([Money(150), Money(275)])),39        "sum_without_radd": attempt(lambda: sum([NoRadd(1), NoRadd(2)])),40        "money_plus_str": attempt(lambda: Money(1) + "x"),41    }

Ordering and truthiness

sorted, min and max only need __lt__. For a > b, Python tries a.__gt__(b) and, if that is not defined, the reflected b.__lt__(a). functools.total_ordering fills in the remaining comparisons from __eq__ plus one of them. An object with __len__ and no __bool__ is falsy when its length is zero, exactly like an empty list.

1class Card:2    ORDER = "23456789TJQKA"3 4    def __init__(self, rank):5        self.rank = rank6 7    def __repr__(self):8        return f"Card({self.rank!r})"9 10    def __lt__(self, other):11        return Card.ORDER.index(self.rank) < Card.ORDER.index(other.rank)12 13 14class Inbox:15    def __init__(self, messages):16        self.messages = list(messages)17 18    def __len__(self):19        return len(self.messages)20 21 22def run():23    hand = [Card("K"), Card("3"), Card("A"), Card("T")]24    return {25        "sorted": repr(sorted(hand)),26        "max": repr(max(hand)),27        "ace_gt_king": Card("A") > Card("K"),28        "empty_is_truthy": bool(Inbox([])),29        "full_is_truthy": bool(Inbox(["hi"])),30    }

Common mistakes

• Defining __eq__ and forgetting __hash__. Every attempt to put the object in a set or use it as a key now fails with unhashable type.
• Hashing a field that __eq__ ignores, or a field that changes later. Equal objects then get different hashes, so a set keeps both, and an object whose hash changed after insertion can no longer be found.
• Returning False from __eq__ or raising TypeError from __add__ for an unknown type, instead of returning NotImplemented.
• Writing only __str__. Logs, debuggers and containers use repr.

What interviewers ask

• What is the relationship between __eq__ and __hash__? Equal objects must hash equal; defining __eq__ alone makes the class unhashable, and a mutable object should usually stay that way.
• __repr__ against __str__? Unambiguous for developers against readable for users; str falls back to , not the other way.