What Are Dunder (Magic) Methods?

Dunder methods — double underscore on both sides — are the hooks the interpreter calls for built-in operations. You do not call them directly; the syntax calls them for you.

class Temperature:
    def __init__(self, celsius):
        self.celsius = celsius

    def __repr__(self):
        return f"Temperature({self.celsius})"

    def __str__(self):
        return f"{self.celsius} C"

    def __len__(self):
        return 3

    def __eq__(self, other):
        return isinstance(other, Temperature) and self.celsius == other.celsius


t = Temperature(20)
print(t)                       # 20 C
print(repr(t))                 # Temperature(20)
print(len(t))                  # 3
print(t == Temperature(20))    # True

Printing the object calls str, which falls back to repr when __str__ is not defined. Calling repr on it directly calls the other method, which is the one aimed at developers — the representation should ideally be valid Python source that recreates the object.

len() calls __len__, and the == operator calls __eq__. Notice that defining __eq__ is enough to make the == comparison work, and that the implementation checks the type of the other operand first so the comparison returns False rather than raising when the types differ.

One consequence worth knowing. Defining __eq__ sets __hash__ to None unless you define it explicitly, which makes instances unhashable and therefore unusable as dictionary keys. If you want equality and hashability, you must write both — and they must agree, since two objects that compare equal must hash the same.

__repr__ is aimed at developers and __str__ is aimed at people. When a class defines only __repr__, both str(obj) and repr(obj) produce the same thing.

class Point:
    def __init__(self, x):
        self.x = x

    def __repr__(self):
        return f"Point({self.x})"

    def __eq__(self, other):
        return isinstance(other, Point) and self.x == other.x

    def __hash__(self):
        return hash(self.x)


p = Point(1)
print(repr(p))                    # Point(1)
print(str(p) == repr(p))          # True - no __str__, so repr is used
print(hash(p) == hash(Point(1)))  # True
print({Point(1): "one"}[p])       # one

The dictionary lookup at the end is the interesting part. The key Point(1) and the lookup key p are different objects, but the dictionary finds the entry because hashing and equality both succeed — a hash bucket match followed by an == check.

That only works because __hash__ was defined. Defining __eq__ without __hash__ makes the class unhashable, and putting an instance in a dictionary raises a TypeError. The rule is that two objects which compare equal must have the same hash, so when you write __eq__ you must decide deliberately what the hash should be.

On the difference between the two methods, the convention is that __repr__ should return something a developer can read unambiguously, ideally a string that would recreate the object, while __str__ can be a friendlier description. If you only write one, write __repr__ — it is the more useful of the two, because it appears in tracebacks, in the debugger and in the interactive prompt.

Dunder methods — sometimes called magic or special methods — are the names that let your objects participate in Python's built-in operations. The name is because they are surrounded by double underscores: __repr__, __len__, __eq__, __add__, __iter__ and so on.

The interpreter finds them by name lookup on the type, not on the instance. When you write len(obj), Python looks up __len__ on the object's class. That means the method must be defined on the class, and a special method on an instance is ignored — which is a common surprise, because instance attribute lookup happens first for ordinary attributes but not for dunder methods.

The ones most worth knowing for interviews are the display and container ones. __repr__ and __str__ control how an object prints. __eq__, __lt__ and the rest of the comparison methods control how it compares — and defining __eq__ means you also need __hash__ unless you want the class to be unhashable. __len__ and __getitem__ give you length and indexing, and __iter__ and __next__ make the object iterable. The arithmetic operators map to __add__, __sub__ and the rest, and the context manager methods __enter__ and __exit__ are what the with statement calls.

Two practical notes. __init__ and __new__ are dunder methods too, and they are the ones you write most often. And the naming convention is fixed — __repr__ is looked up by that exact name, so a method called __repr_ or __repr__ with different capitalisation will simply never be called.