← Python

Magic/Dunder Methods & Protocols

← Magic/Dunder Methods & Protocols

Select a question from the sidebar

15 questions in this topic

Question 1 / 15

What is the difference between `repr` and `str`, and when is each called?

__repr__ and __str__ both produce string representations, but they serve different audiences:

__repr__: Developer-facing. Should be unambiguous and ideally return a string that could recreate the object (eval(repr(obj)) == obj). Called by repr(), the interactive interpreter, and when objects are displayed inside containers (lists, dicts).

__str__: User-facing. Should be readable and informative. Called by str(), print(), and f-strings.

Fallback behavior: If __str__ is not defined, Python uses __repr__ as the fallback. The reverse is NOT true -- missing __repr__ falls back to the default object.__repr__ (e.g., <MyClass object at 0x...>).

Priority rule: Always implement __repr__. Only add __str__ if you need a different user-facing representation.

Pseudo Code

1. repr(obj) -> obj.__repr__()
2. str(obj), print(obj), f'{obj}' -> obj.__str__()
3. If __str__ missing -> falls back to __repr__
4. Containers (list, dict) always use __repr__ for elements
5. Interactive console uses __repr__

Code

from datetime import datetime

class Transaction:
    def __init__(self, amount, currency, timestamp=None):
        self.amount = amount
        self.currency = currency
        self.timestamp = timestamp or datetime.now()

    def __repr__(self):
        return (f"Transaction({self.amount!r}, {self.currency!r}, "
                f"timestamp={self.timestamp!r})")

    def __str__(self):
        return f"{self.currency} {self.amount:,.2f}"

t = Transaction(1234.5, "USD")

# __repr__ -- for developers
print(repr(t))  # Transaction(1234.5, 'USD', timestamp=datetime.datetime(...))

# __str__ -- for users
print(str(t))   # USD 1,234.50
print(t)        # USD 1,234.50 (print uses __str__)
print(f"Payment: {t}")  # Payment: USD 1,234.50 (f-string uses __str__)
print(f"Debug: {t!r}")  # Debug: Transaction(...) (f-string with !r uses __repr__)

# Containers ALWAYS use __repr__
transactions = [Transaction(100, "USD"), Transaction(200, "EUR")]
print(transactions)  # [Transaction(100, 'USD', ...), Transaction(200, 'EUR', ...)]

# Without __str__, __repr__ is used everywhere
class OnlyRepr:
    def __repr__(self):
        return "OnlyRepr()"

obj = OnlyRepr()
print(str(obj))   # OnlyRepr() -- falls back to __repr__
print(repr(obj))  # OnlyRepr()

# Use !r in __repr__ to quote strings properly
class User:
    def __init__(self, name):
        self.name = name
    def __repr__(self):
        return f"User({self.name!r})"  # !r adds quotes: User('Alice')

print(repr(User("Alice")))  # User('Alice')

Transaction(1234.5, 'USD', timestamp=datetime.datetime(<timestamp>))
USD 1,234.50
USD 1,234.50
Payment: USD 1,234.50
Debug: Transaction(1234.5, 'USD', timestamp=datetime.datetime(<timestamp>))
[Transaction(100, 'USD', timestamp=datetime.datetime(<timestamp>)), Transaction(200, 'EUR', timestamp=datetime.datetime(2026, 3, 18, 11, 27, 24, 761968))]
OnlyRepr()
OnlyRepr()
User('Alice')

Key Points

•__repr__ for developers (unambiguous), __str__ for users (readable)
•Containers use __repr__ for elements, not __str__
•__str__ falls back to __repr__ if not defined
•Use !r in f-strings to force __repr__

Gotchas

•print([obj]) uses __repr__, not __str__ -- surprising for beginners
•If you only implement __str__, debugging output shows unhelpful <object at 0x...>
•eval(repr(obj)) == obj is an ideal, not always achievable

__repr__ is developer-facing (debugging), __str__ is user-facing (display). Containers use __repr__. If __str__ is missing, __repr__ is the fallback.

•__repr__ for debugging, __str__ for display
•Always implement __repr__; __str__ is optional

class Money:
    def __init__(self, amount):
        self.amount = amount
    def __repr__(self):
        return f"Money({self.amount!r})"
    def __str__(self):
        return f"${self.amount:.2f}"

m = Money(42.5)
print(repr(m))  # Money(42.5)
print(str(m))   # $42.50
print([m])      # [Money(42.5)]  -- container uses __repr__

Money(42.5)
$42.50
[Money(42.5)]

Containers always use __repr__ for their elements

Question 2 / 15

How do `eq` and `hash` work together, and what are the rules?

Python's __eq__ defines value equality (==) and __hash__ returns an integer hash for use in sets and dict keys.

Critical rules:

If a == b, then hash(a) == hash(b) MUST be true
If you define __eq__, Python sets __hash__ to None (unhashable)
You must explicitly define __hash__ if you want hashability with custom __eq__
Hash should be based on the same immutable fields used in __eq__
Equal objects MUST have equal hashes; unequal objects MAY have equal hashes (collisions are OK)

Default behavior (no __eq__ defined): equality is identity (is), hash is based on id().

Return NotImplemented from __eq__ when comparing with unsupported types -- this lets Python try the other operand's __eq__.

Pseudo Code

Rules:
1. a == b implies hash(a) == hash(b)
2. Define __eq__ -> Python sets __hash__ = None
3. Must explicitly re-define __hash__ for sets/dict keys
4. Hash from same fields as __eq__
5. Use hash(tuple_of_fields) for consistent hashing

Code

class Color:
    def __init__(self, r, g, b):
        self.r = r
        self.g = g
        self.b = b

    def __eq__(self, other):
        if not isinstance(other, Color):
            return NotImplemented
        return (self.r, self.g, self.b) == (other.r, other.g, other.b)

    def __hash__(self):
        return hash((self.r, self.g, self.b))

    def __repr__(self):
        return f"Color({self.r}, {self.g}, {self.b})"

# Equality works
c1 = Color(255, 0, 0)
c2 = Color(255, 0, 0)
c3 = Color(0, 255, 0)

print(c1 == c2)  # True
print(c1 == c3)  # False
print(c1 == "red")  # False (NotImplemented -> Python returns False)

# Hashable -- works in sets and dicts
colors = {c1, c2, c3}  # c1 and c2 are deduplicated
print(len(colors))  # 2

color_names = {Color(255, 0, 0): "red", Color(0, 255, 0): "green"}
print(color_names[Color(255, 0, 0)])  # "red" -- lookup works

# What happens without __hash__
class NoHash:
    def __eq__(self, other):
        return True

try:
    {NoHash()}  # TypeError: unhashable type
except TypeError as e:
    print(e)  # unhashable type: 'NoHash'

# Mutable objects should generally not be hashable
class MutablePoint:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __eq__(self, other):
        if not isinstance(other, MutablePoint):
            return NotImplemented
        return (self.x, self.y) == (other.x, other.y)

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

# DANGER: mutating after adding to set breaks things
s = set()
p = MutablePoint(1, 2)
s.add(p)
print(p in s)  # True
p.x = 99       # mutate!
print(p in s)  # False! Hash changed, can't find it
# The object is still in the set but unreachable!

True
False
False
2
red
unhashable type: 'NoHash'
True
False

Key Points

•Equal objects MUST have equal hashes
•Defining __eq__ sets __hash__ to None -- must re-define
•Use hash(tuple_of_fields) for consistent hashing
•Return NotImplemented for unsupported comparison types

Gotchas

•Mutating an object after adding to a set makes it unreachable
•Return NotImplemented (not NotImplementedError) from __eq__
•Without __hash__, instances can't be in sets or dict keys
•Hash collisions are OK (performance penalty only); unequal hashes for equal objects are BUGS

Define __eq__ and __hash__ together on the same fields. Equal objects must have equal hashes. Defining __eq__ without __hash__ makes instances unhashable.

•a == b implies hash(a) == hash(b)
•hash() from same fields as __eq__

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y
    def __eq__(self, other):
        if not isinstance(other, Point): return NotImplemented
        return (self.x, self.y) == (other.x, other.y)
    def __hash__(self):
        return hash((self.x, self.y))

print({Point(1,2), Point(1,2), Point(3,4)})  # 2 unique points

{<__main__.Point object at <address>>, <__main__.Point object at <address>>}  # (order may vary)

Mutating hashed objects in sets makes them unreachable

Question 3 / 15

How do comparison dunder methods work, and what is `@total_ordering`?

Python provides six comparison dunder methods:

__eq__ (==), __ne__ (!=)
__lt__ (<), __le__ (<=)
__gt__ (>), __ge__ (>=)

By default, only __eq__ and __ne__ are defined (based on identity). The ordering methods (__lt__, __le__, etc.) are not automatically derived from each other.

@functools.total_ordering is a class decorator that generates the missing ordering methods from __eq__ and one of __lt__, __le__, __gt__, or __ge__. This saves you from implementing all four manually.

Important: Return NotImplemented (not NotImplementedError) when the comparison doesn't make sense for the given types. This tells Python to try the reflected operation on the other operand.

Pseudo Code

1. Define __eq__ for equality
2. Define one ordering method (__lt__ is conventional)
3. Apply @total_ordering to generate the rest
4. Always return NotImplemented for unsupported types
5. Compare using tuples for multi-field ordering

Code

from functools import total_ordering

@total_ordering
class Version:
    def __init__(self, major, minor, patch):
        self.major = major
        self.minor = minor
        self.patch = patch

    def __eq__(self, other):
        if not isinstance(other, Version):
            return NotImplemented
        return self._tuple == other._tuple

    def __lt__(self, other):
        if not isinstance(other, Version):
            return NotImplemented
        return self._tuple < other._tuple

    @property
    def _tuple(self):
        return (self.major, self.minor, self.patch)

    def __repr__(self):
        return f"Version({self.major}.{self.minor}.{self.patch})"

v1 = Version(1, 0, 0)
v2 = Version(1, 2, 0)
v3 = Version(1, 2, 3)
v4 = Version(1, 2, 3)

# All comparisons work with just __eq__ and __lt__
print(v1 < v2)   # True
print(v2 <= v3)  # True  (generated by @total_ordering)
print(v3 > v1)   # True  (generated)
print(v3 >= v4)  # True  (generated)
print(v3 == v4)  # True
print(v1 != v2)  # True

# Sorting works automatically
versions = [v3, v1, v2]
print(sorted(versions))  # [Version(1.0.0), Version(1.2.0), Version(1.2.3)]

# Without @total_ordering, implement all methods manually
class Temperature:
    def __init__(self, celsius):
        self.celsius = celsius

    def __eq__(self, other):
        if not isinstance(other, Temperature):
            return NotImplemented
        return self.celsius == other.celsius

    def __lt__(self, other):
        if not isinstance(other, Temperature):
            return NotImplemented
        return self.celsius < other.celsius

    def __le__(self, other):
        if not isinstance(other, Temperature):
            return NotImplemented
        return self.celsius <= other.celsius

    def __gt__(self, other):
        if not isinstance(other, Temperature):
            return NotImplemented
        return self.celsius > other.celsius

    def __ge__(self, other):
        if not isinstance(other, Temperature):
            return NotImplemented
        return self.celsius >= other.celsius

# NotImplemented allows Python to try the other side
print(v1 == "1.0.0")  # False (str.__eq__ also returns NotImplemented)
try:
    print(v1 < 5)
except TypeError as e:
    print(f"TypeError: {e}")  # both sides return NotImplemented

True
True
True
True
True
True
[Version(1.0.0), Version(1.2.0), Version(1.2.3)]
False
TypeError: '<' not supported between instances of 'Version' and 'int'

Key Points

•@total_ordering generates missing comparisons from __eq__ + one ordering method
•Return NotImplemented for unsupported types, not False or NotImplementedError
•Use tuple comparison for multi-field ordering
•Sorted() and min()/max() use __lt__ by default

Gotchas

•@total_ordering has slight performance overhead -- implement all methods for hot paths
•Return NotImplemented (a singleton), not NotImplementedError (an exception)
•__ne__ is auto-derived from __eq__ in Python 3 (returns not __eq__)
•Comparing incompatible types raises TypeError if both sides return NotImplemented

@total_ordering generates <=, >, >= from __eq__ + __lt__. Return NotImplemented for unsupported types. Use tuple comparison for multi-field ordering.

•@total_ordering fills in missing comparisons
•Return NotImplemented for type mismatches

from functools import total_ordering

@total_ordering
class Score:
    def __init__(self, value):
        self.value = value
    def __eq__(self, other):
        if not isinstance(other, Score): return NotImplemented
        return self.value == other.value
    def __lt__(self, other):
        if not isinstance(other, Score): return NotImplemented
        return self.value < other.value

print(Score(5) < Score(10))   # True
print(Score(10) >= Score(5))  # True (generated)

True
True

Return NotImplemented, not NotImplementedError

Question 4 / 15

How do arithmetic dunder methods like `add` and `radd` work?

Python uses dunder methods for operator overloading. For a + b, Python calls a.__add__(b). If that returns NotImplemented, Python tries b.__radd__(a) (the reflected/right-hand version).

The arithmetic dunders are:

__add__ (+), __sub__ (-), __mul__ (*), __truediv__ (/)
__floordiv__ (//), __mod__ (%), __pow__ (**)
__radd__, __rsub__, etc. -- reflected versions
__iadd__, __isub__, etc. -- in-place versions (+=, -=)

The r (reflected) variants handle the case where the left operand doesn't know how to handle the operation. The i (in-place) variants handle augmented assignment and should modify self and return it.

Return NotImplemented when the operation doesn't make sense for the given types.

Pseudo Code

a + b:
1. Try a.__add__(b)
2. If NotImplemented, try b.__radd__(a)
3. If both NotImplemented, raise TypeError

a += b:
1. Try a.__iadd__(b)
2. If not defined or NotImplemented, fall back to a = a.__add__(b)
3. If immutable type, creates new object

Code

class Vector:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __add__(self, other):
        if isinstance(other, Vector):
            return Vector(self.x + other.x, self.y + other.y)
        if isinstance(other, (int, float)):
            return Vector(self.x + other, self.y + other)
        return NotImplemented

    def __radd__(self, other):
        # Called when other + self and other.__add__ returns NotImplemented
        return self.__add__(other)

    def __mul__(self, scalar):
        if isinstance(scalar, (int, float)):
            return Vector(self.x * scalar, self.y * scalar)
        return NotImplemented

    def __rmul__(self, scalar):
        return self.__mul__(scalar)

    def __iadd__(self, other):
        # In-place addition (+=)
        if isinstance(other, Vector):
            self.x += other.x
            self.y += other.y
            return self  # MUST return self for in-place
        return NotImplemented

    def __neg__(self):
        return Vector(-self.x, -self.y)

    def __abs__(self):
        return (self.x ** 2 + self.y ** 2) ** 0.5

    def __repr__(self):
        return f"Vector({self.x}, {self.y})"

# Vector + Vector
v1 = Vector(1, 2)
v2 = Vector(3, 4)
print(v1 + v2)  # Vector(4, 6)

# Vector + scalar and scalar + Vector
print(v1 + 10)  # Vector(11, 12) -- __add__
print(10 + v1)   # Vector(11, 12) -- __radd__

# Scalar * Vector and Vector * scalar
print(v1 * 3)   # Vector(3, 6) -- __mul__
print(3 * v1)    # Vector(3, 6) -- __rmul__

# In-place addition
v1 += v2
print(v1)  # Vector(4, 6) -- modified in-place

# Unary operators
print(-v2)    # Vector(-3, -4)
print(abs(v2))  # 5.0

# NotImplemented triggers reflected method
class Money:
    def __init__(self, amount):
        self.amount = amount
    def __add__(self, other):
        if isinstance(other, Money):
            return Money(self.amount + other.amount)
        return NotImplemented  # let other.__radd__ handle it
    def __repr__(self):
        return f"Money({self.amount})"

print(Money(10) + Money(20))  # Money(30)
# Money(10) + "hello"  # TypeError: both sides return NotImplemented

Vector(4, 6)
Vector(11, 12)
Vector(11, 12)
Vector(3, 6)
Vector(3, 6)
Vector(4, 6)
Vector(-3, -4)
5.0
Money(30)

Key Points

•a + b tries a.__add__(b), then b.__radd__(a)
•__iadd__ handles +=, must return self for in-place mutation
•Return NotImplemented for unsupported types (not TypeError)
•__rmul__/__radd__ handle reversed operand cases

Gotchas

•__iadd__ must return self for mutable objects; for immutables, += creates a new object
•If __radd__ is not defined, reversed operations raise TypeError
•Return NotImplemented, not None or raise TypeError -- let Python handle the error
•Subclass __radd__ has priority over parent __add__ (Python checks subclass first)

a + b calls a.__add__(b), failing that tries b.__radd__(a). __iadd__ handles +=. Return NotImplemented for unsupported types.

•__add__ for +, __radd__ for reversed, __iadd__ for +=
•Return NotImplemented for unsupported types

class Vec:
    def __init__(self, x, y):
        self.x, self.y = x, y
    def __add__(self, other):
        if isinstance(other, Vec):
            return Vec(self.x + other.x, self.y + other.y)
        return NotImplemented
    def __repr__(self):
        return f"Vec({self.x}, {self.y})"

print(Vec(1, 2) + Vec(3, 4))  # Vec(4, 6)

Vec(4, 6)

__iadd__ must return self for mutable objects

Question 5 / 15

How do `len`, `getitem`, `setitem`, and `contains` make a class behave like a sequence?

Python's data model lets you make any class behave like a built-in sequence (list, tuple) by implementing specific dunder methods:

__len__: Called by len(). Returns the number of items.
__getitem__: Called by obj[key]. Enables indexing and slicing. Also makes the object iterable (Python falls back to __getitem__ with integer indices if __iter__ is not defined).
__setitem__: Called by obj[key] = value. Enables item assignment.
__delitem__: Called by del obj[key]. Enables item deletion.
__contains__: Called by in operator. If not defined, Python falls back to iterating with __iter__ or __getitem__.

Implementing __getitem__ alone is enough for iteration, in operator, and unpacking to work.

Pseudo Code

1. __len__(self) -> len(obj)
2. __getitem__(self, index) -> obj[index], obj[start:stop]
3. __setitem__(self, index, value) -> obj[index] = value
4. __delitem__(self, index) -> del obj[index]
5. __contains__(self, item) -> item in obj
6. Just __getitem__ enables: iteration, in, unpacking

Code

class Playlist:
    def __init__(self, name, songs=None):
        self.name = name
        self._songs = list(songs or [])

    def __len__(self):
        return len(self._songs)

    def __getitem__(self, index):
        # Supports both indexing and slicing
        if isinstance(index, slice):
            return Playlist(f"{self.name} (slice)", self._songs[index])
        return self._songs[index]

    def __setitem__(self, index, value):
        self._songs[index] = value

    def __delitem__(self, index):
        del self._songs[index]

    def __contains__(self, item):
        return item in self._songs

    def __repr__(self):
        return f"Playlist({self.name!r}, {self._songs!r})"

pl = Playlist("Rock", ["Bohemian Rhapsody", "Stairway to Heaven", "Hotel California"])

# __len__
print(len(pl))  # 3

# __getitem__ -- indexing
print(pl[0])    # Bohemian Rhapsody
print(pl[-1])   # Hotel California

# __getitem__ -- slicing
print(pl[0:2])  # Playlist('Rock (slice)', ['Bohemian Rhapsody', 'Stairway to Heaven'])

# __setitem__
pl[1] = "Back in Black"
print(pl[1])  # Back in Black

# __delitem__
del pl[2]
print(len(pl))  # 2

# __contains__
print("Back in Black" in pl)  # True
print("Missing Song" in pl)   # False

# __getitem__ enables iteration automatically
for song in pl:
    print(song)
# Bohemian Rhapsody
# Back in Black

# Unpacking works too
a, b = pl
print(a, b)  # Bohemian Rhapsody Back in Black

# reversed() works if __getitem__ + __len__ are defined
for song in reversed(pl):
    print(song)
# Back in Black
# Bohemian Rhapsody

3
Bohemian Rhapsody
Hotel California
Playlist('Rock (slice)', ['Bohemian Rhapsody', 'Stairway to Heaven'])
Back in Black
2
True
False
Bohemian Rhapsody
Back in Black
Bohemian Rhapsody Back in Black
Back in Black
Bohemian Rhapsody

Key Points

•__getitem__ alone enables indexing, iteration, and unpacking
•__len__ + __getitem__ enable reversed()
•__contains__ optimizes 'in' operator (otherwise Python iterates)
•Handle slice objects in __getitem__ for slicing support

Gotchas

•Without __contains__, 'in' falls back to iterating the entire sequence (O(n))
•__getitem__ must raise IndexError for out-of-range indices to stop iteration
•Slicing passes a slice object, not individual indices -- check isinstance(index, slice)
•Implementing __getitem__ without __len__ means len() doesn't work but iteration does

Implement __len__, __getitem__, __setitem__, __contains__ to make a class behave like a list. Just __getitem__ alone enables iteration, in, and unpacking.

•__getitem__ enables indexing and iteration
•__contains__ optimizes 'in' operator

class MyList:
    def __init__(self, items):
        self._items = list(items)
    def __len__(self):
        return len(self._items)
    def __getitem__(self, index):
        return self._items[index]
    def __contains__(self, item):
        return item in self._items

m = MyList([10, 20, 30])
print(len(m))       # 3
print(m[1])         # 20
print(20 in m)      # True
for x in m: print(x)  # iteration works

3
20
True
10
20
30

__getitem__ must raise IndexError to stop iteration

Question 6 / 15

How does the `call` method work, and when would you use it?

__call__ makes instances of a class callable like functions. When you write obj(), Python calls obj.__call__(). Any object with __call__ passes the callable() test.

Use cases:

Stateful functions: Objects that maintain state between calls (counters, accumulators)
Decorators: Class-based decorators use __call__ as the wrapper
Strategy pattern: Swappable callables with configurable behavior
Callbacks: Objects that behave like functions but carry extra state
Function factories: More readable than closures for complex cases

Pseudo Code

1. Define __call__(self, *args, **kwargs) on a class
2. Instances can be called like functions: obj(args)
3. callable(obj) returns True
4. Useful for stateful functions, decorators, strategies

Code

class Counter:
    """Callable that counts invocations."""
    def __init__(self, start=0):
        self.count = start

    def __call__(self, increment=1):
        self.count += increment
        return self.count

    def reset(self):
        self.count = 0

counter = Counter()
print(counter())   # 1
print(counter())   # 2
print(counter(5))  # 7
print(callable(counter))  # True
counter.reset()
print(counter())   # 1

# Use case: configurable validator
class RangeValidator:
    def __init__(self, min_val, max_val):
        self.min_val = min_val
        self.max_val = max_val

    def __call__(self, value):
        if not self.min_val <= value <= self.max_val:
            raise ValueError(
                f"{value} not in range [{self.min_val}, {self.max_val}]"
            )
        return True

validate_age = RangeValidator(0, 150)
validate_score = RangeValidator(0, 100)

print(validate_age(25))    # True
print(validate_score(95))  # True

try:
    validate_age(200)
except ValueError as e:
    print(e)  # 200 not in range [0, 150]

# Use case: memoized function as a class
class Memoize:
    def __init__(self, func):
        self.func = func
        self.cache = {}

    def __call__(self, *args):
        if args not in self.cache:
            self.cache[args] = self.func(*args)
        return self.cache[args]

@Memoize
def fibonacci(n):
    if n < 2:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

print(fibonacci(10))  # 55
print(fibonacci.cache)  # {(0,): 0, (1,): 1, (2,): 1, ...}

# callable() check
print(callable(counter))   # True
print(callable(len))       # True
print(callable(42))        # False
print(callable("string"))  # False

1
2
7
True
1
True
True
200 not in range [0, 150]
55
{(1,): 1, (0,): 0, (2,): 1, (3,): 2, (4,): 3, (5,): 5, (6,): 8, (7,): 13, (8,): 21, (9,): 34, (10,): 55}
True
True
False
False

Key Points

•__call__ makes instances callable with obj() syntax
•callable(obj) returns True for objects with __call__
•Used for stateful functions, validators, decorators
•Carries state between calls (advantage over plain functions)

Gotchas

•Class-based callables don't work as bound methods without implementing __get__
•__call__ can accept any signature -- document it clearly
•Overusing __call__ can make code confusing -- it's not obvious what obj() does

__call__ makes instances callable like functions. obj() triggers obj.__call__(). Used for stateful functions, validators, and class-based decorators.

•obj() triggers __call__
•Used for stateful callables

class Adder:
    def __init__(self, n):
        self.n = n
    def __call__(self, x):
        return self.n + x

add5 = Adder(5)
print(add5(10))       # 15
print(callable(add5)) # True

15
True

Not obvious what obj() does -- document clearly

Question 7 / 15

How do `enter` and `exit` implement the context manager protocol?

The context manager protocol consists of two methods:

__enter__(self): Called when entering the with block. Its return value is bound to the variable after as.

__exit__(self, exc_type, exc_val, exc_tb): Called when leaving the with block, whether normally or due to an exception. The three parameters describe any exception that occurred:

exc_type: Exception class (or None)
exc_val: Exception instance (or None)
exc_tb: Traceback object (or None)

If __exit__ returns a truthy value, the exception is suppressed. If it returns a falsy value (or None), the exception propagates.

Common uses: file handling, database transactions, locks, timing, temporary state changes.

Pseudo Code

with manager as value:
    1. value = manager.__enter__()
    2. Execute block
    3. If exception: __exit__(exc_type, exc_val, exc_tb)
       If no exception: __exit__(None, None, None)
    4. If __exit__ returns True, exception is suppressed
    5. If __exit__ returns False/None, exception propagates

Code

import time

class Timer:
    """Context manager that measures execution time."""
    def __enter__(self):
        self.start = time.perf_counter()
        return self  # bound to 'as' variable

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.elapsed = time.perf_counter() - self.start
        print(f"Elapsed: {self.elapsed:.4f}s")
        return False  # don't suppress exceptions

with Timer() as t:
    total = sum(range(1_000_000))
print(f"Result: {total}, took {t.elapsed:.4f}s")

# Context manager for database transactions
class Transaction:
    def __init__(self, connection):
        self.conn = connection

    def __enter__(self):
        print("BEGIN transaction")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is None:
            print("COMMIT")
        else:
            print(f"ROLLBACK due to {exc_type.__name__}: {exc_val}")
        return False  # propagate exceptions

# Exception suppression
class Suppress:
    """Suppress specific exceptions."""
    def __init__(self, *exceptions):
        self.exceptions = exceptions

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is not None and issubclass(exc_type, self.exceptions):
            self.exception = exc_val
            return True  # suppress the exception
        return False

with Suppress(FileNotFoundError, PermissionError):
    open("/nonexistent/file")  # FileNotFoundError suppressed

print("Execution continues!")  # This runs

# Context manager for temporary state
class TempDirectory:
    def __init__(self):
        import os
        self.original = os.getcwd()

    def __enter__(self):
        import tempfile
        self.tmpdir = tempfile.mkdtemp()
        import os
        os.chdir(self.tmpdir)
        return self.tmpdir

    def __exit__(self, exc_type, exc_val, exc_tb):
        import os
        import shutil
        os.chdir(self.original)
        shutil.rmtree(self.tmpdir)
        return False

Elapsed: <time>s
Result: 499999500000, took <time>s
Execution continues!

Key Points

•__enter__ runs on 'with' entry, return value bound to 'as' variable
•__exit__ runs on exit, receives exception info (or None)
•Return True from __exit__ to suppress exceptions
•Use for resource management: files, locks, transactions, temp state

Gotchas

•__exit__ is called even if __enter__ raises (if the with block was entered)
•Returning True from __exit__ suppresses ALL exceptions of that type -- be very specific
•If __enter__ raises, __exit__ is NOT called -- the with block was never entered
•__enter__ must return self (or the managed resource), not the result of some operation

__enter__ runs on with entry (return value goes to as). __exit__ runs on exit with exception info. Return True from __exit__ to suppress exceptions.

•__enter__ returns resource, __exit__ cleans up
•Return True to suppress exceptions

class Timer:
    def __enter__(self):
        import time
        self.start = time.perf_counter()
        return self
    def __exit__(self, *args):
        import time
        self.elapsed = time.perf_counter() - self.start
        return False

with Timer() as t:
    sum(range(1_000_000))
print(f"{t.elapsed:.4f}s")

<time>s

__exit__ not called if __enter__ raises

Question 8 / 15

How do `iter` and `next` implement the iterator protocol?

Python's iteration protocol requires two methods:

Iterable: An object with __iter__() that returns an iterator. Iterables can be looped over multiple times.

Iterator: An object with both __iter__() (returns self) and __next__() (returns next value or raises StopIteration). Iterators are exhaustible -- once done, they're empty.

for x in obj works by:

Calling iter(obj) which calls obj.__iter__() to get an iterator
Repeatedly calling next(iterator) which calls iterator.__next__()
Stopping when StopIteration is raised

Separating iterable from iterator allows multiple independent iterations over the same data.

Pseudo Code

Iterable: class with __iter__() returning an iterator
Iterator: class with __iter__() returning self + __next__()

for x in iterable:
  1. iterator = iter(iterable)  # calls __iter__
  2. while True:
  3.   try: x = next(iterator)  # calls __next__
  4.   except StopIteration: break

Code

# Separate iterable and iterator (best practice)
class Countdown:
    """Iterable: can be iterated multiple times."""
    def __init__(self, start):
        self.start = start

    def __iter__(self):
        return CountdownIterator(self.start)

class CountdownIterator:
    """Iterator: exhaustible, one-pass."""
    def __init__(self, current):
        self.current = current

    def __iter__(self):
        return self  # iterators return themselves

    def __next__(self):
        if self.current <= 0:
            raise StopIteration
        value = self.current
        self.current -= 1
        return value

cd = Countdown(3)

# Can iterate multiple times
for n in cd:
    print(n, end=" ")  # 3 2 1
print()

for n in cd:
    print(n, end=" ")  # 3 2 1 (fresh iterator each time)
print()

# Combined iterable + iterator (simpler but single-pass)
class SinglePassRange:
    def __init__(self, n):
        self.n = n
        self.current = 0

    def __iter__(self):
        return self

    def __next__(self):
        if self.current >= self.n:
            raise StopIteration
        value = self.current
        self.current += 1
        return value

r = SinglePassRange(3)
print(list(r))  # [0, 1, 2]
print(list(r))  # [] -- exhausted!

# Practical: file-like line iterator
class LineReader:
    def __init__(self, text):
        self.lines = text.split("\n")

    def __iter__(self):
        return iter(self.lines)  # delegate to list iterator

    def __len__(self):
        return len(self.lines)

reader = LineReader("line1\nline2\nline3")
for line in reader:
    print(line)

# Manual iteration with iter() and next()
it = iter([10, 20, 30])
print(next(it))  # 10
print(next(it))  # 20
print(next(it))  # 30
print(next(it, "default"))  # "default" (instead of StopIteration)

3 2 1
3 2 1
[0, 1, 2]
[]
line1
line2
line3
10
20
30
default

Key Points

•Iterable has __iter__() returning an iterator; Iterator has __iter__() + __next__()
•Separate iterable from iterator for multi-pass iteration
•__next__() raises StopIteration when exhausted
•next(iter, default) avoids StopIteration exception

Gotchas

•Combined iterable+iterator can only be iterated once (exhaustible)
•Forgetting to raise StopIteration causes infinite loops
•Iterators should return self from __iter__ (required by protocol)
•Modifying the underlying collection during iteration causes undefined behavior

Iterable has __iter__() returning an iterator. Iterator has __iter__() + __next__(). Raise StopIteration when done. Separate iterable from iterator for multi-pass.

•__iter__ returns iterator, __next__ returns values
•StopIteration signals end of iteration

class Range:
    def __init__(self, n):
        self.n = n
    def __iter__(self):
        self.i = 0
        return self
    def __next__(self):
        if self.i >= self.n:
            raise StopIteration
        val = self.i
        self.i += 1
        return val

for x in Range(3):
    print(x)  # 0, 1, 2

0
1
2

Combined iterable+iterator is single-pass only

Question 9 / 15

How does `bool` work, and what determines the truthiness of an object?

When Python needs a boolean value (in if, while, and, or, not), it calls bool(obj) which follows this lookup:

__bool__: If defined, its return value is used
__len__: If __bool__ is not defined but __len__ is, the object is truthy if len(obj) != 0
Default: If neither is defined, the object is always truthy

Built-in falsy values: None, False, 0, 0.0, 0j, '', [], (), {}, set(), frozenset(), range(0).

Defining __bool__ gives you control over when your objects are considered truthy or falsy. This is useful for objects that represent states (empty/non-empty, valid/invalid, connected/disconnected).

Pseudo Code

bool(obj):
1. If __bool__ defined: return obj.__bool__()
2. Elif __len__ defined: return len(obj) != 0
3. Else: return True (all objects are truthy by default)

Falsy: None, False, 0, 0.0, '', [], {}, set()
Everything else is truthy

Code

# __bool__ for custom truthiness
class Connection:
    def __init__(self, host):
        self.host = host
        self.connected = False

    def connect(self):
        self.connected = True

    def __bool__(self):
        return self.connected

conn = Connection("localhost")
print(bool(conn))  # False

if not conn:
    print("Not connected")  # prints

conn.connect()
if conn:
    print("Connected!")  # prints

# __len__ fallback
class Playlist:
    def __init__(self, songs=None):
        self.songs = songs or []

    def __len__(self):
        return len(self.songs)

empty = Playlist()
full = Playlist(["song1", "song2"])

print(bool(empty))  # False (len == 0)
print(bool(full))   # True (len > 0)

if full:
    print(f"{len(full)} songs")  # 2 songs
if not empty:
    print("No songs")  # No songs

# Default: objects without __bool__ or __len__ are truthy
class Plain:
    pass

print(bool(Plain()))  # True

# __bool__ takes priority over __len__
class Weird:
    def __len__(self):
        return 10  # would be truthy

    def __bool__(self):
        return False  # but __bool__ overrides

print(bool(Weird()))  # False (__bool__ wins)
print(len(Weird()))   # 10

# Built-in falsy values
falsy_values = [None, False, 0, 0.0, 0j, "", [], (), {}, set(), frozenset()]
for val in falsy_values:
    assert not val, f"{val!r} should be falsy"

False
Not connected
Connected!
False
True
2 songs
No songs
True
False
10

Key Points

•__bool__ > __len__ > default True for truthiness evaluation
•Containers are falsy when empty (via __len__ returning 0)
•__bool__ must return True or False (not other truthy/falsy values)
•Falsy: None, False, 0, empty containers

Gotchas

•__bool__ must return exactly True or False -- returning an int raises TypeError
•__bool__ overrides __len__ for truthiness, but len() still works independently
•Objects without __bool__ or __len__ are always truthy -- even if logically empty

bool(obj) checks __bool__ first, then __len__ (truthy if non-zero), then defaults to True. Empty containers are falsy via __len__.

•__bool__ > __len__ > True for truthiness
•Empty containers are falsy via __len__

class Result:
    def __init__(self, data=None):
        self.data = data
    def __bool__(self):
        return self.data is not None

print(bool(Result()))       # False
print(bool(Result("ok")))   # True
if Result([1, 2]):
    print("Has data")       # prints

False
True
Has data

__bool__ must return True/False, not other types

Question 10 / 15

What is the descriptor protocol (`get`, `set`, `delete`)?

Descriptors are objects that customize attribute access by implementing __get__, __set__, and/or __delete__. They must be defined as class attributes (not instance attributes) to work.

Data descriptor: Has __set__ or __delete__ (in addition to __get__). Takes priority over instance __dict__. Non-data descriptor: Has only __get__. Instance __dict__ takes priority.

Descriptors power many Python features:

property is a data descriptor
Functions are non-data descriptors (their __get__ creates bound methods)
classmethod and staticmethod are descriptors
__slots__ uses descriptors internally

The descriptor protocol is one of the most fundamental mechanisms in Python's data model.

Pseudo Code

Descriptor methods:
  __get__(self, obj, objtype) -> called on attribute access
  __set__(self, obj, value) -> called on attribute assignment
  __delete__(self, obj) -> called on attribute deletion

Lookup priority:
  1. Data descriptors (has __set__ or __delete__)
  2. Instance __dict__
  3. Non-data descriptors (only __get__)

Code

# Simple descriptor: validated attribute
class Positive:
    """Descriptor that enforces positive values."""
    def __set_name__(self, owner, name):
        self.name = name
        self.private_name = f"_{name}"

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self  # accessed on class, return descriptor
        return getattr(obj, self.private_name, None)

    def __set__(self, obj, value):
        if value <= 0:
            raise ValueError(f"{self.name} must be positive, got {value}")
        setattr(obj, self.private_name, value)

    def __delete__(self, obj):
        delattr(obj, self.private_name)

class Product:
    price = Positive()    # descriptor as class attribute
    quantity = Positive()

    def __init__(self, name, price, quantity):
        self.name = name
        self.price = price        # triggers Positive.__set__
        self.quantity = quantity

p = Product("Widget", 9.99, 100)
print(p.price)     # 9.99 (triggers Positive.__get__)
print(p.quantity)  # 100

try:
    p.price = -5  # triggers Positive.__set__ -> ValueError
except ValueError as e:
    print(e)  # price must be positive, got -5

# How property works (simplified)
class Property:
    def __init__(self, fget=None, fset=None, fdel=None):
        self.fget = fget
        self.fset = fset
        self.fdel = fdel

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self
        if self.fget is None:
            raise AttributeError("unreadable attribute")
        return self.fget(obj)

    def __set__(self, obj, value):
        if self.fset is None:
            raise AttributeError("can't set attribute")
        self.fset(obj, value)

# How functions become bound methods (non-data descriptor)
class Function:
    def __get__(self, obj, objtype=None):
        if obj is None:
            return self  # unbound
        # Return a bound method
        import types
        return types.MethodType(self, obj)

# Data descriptor vs non-data descriptor
class DataDesc:
    def __get__(self, obj, objtype=None):
        return "from data descriptor"
    def __set__(self, obj, value):
        pass  # having __set__ makes it a data descriptor

class NonDataDesc:
    def __get__(self, obj, objtype=None):
        return "from non-data descriptor"

class MyClass:
    data = DataDesc()
    nondata = NonDataDesc()

obj = MyClass()
obj.__dict__['data'] = "from instance"
obj.__dict__['nondata'] = "from instance"

print(obj.data)     # "from data descriptor" -- data desc wins over __dict__
print(obj.nondata)  # "from instance" -- __dict__ wins over non-data desc

9.99
100
price must be positive, got -5
from data descriptor
from instance

Key Points

•Descriptors customize attribute access via __get__, __set__, __delete__
•Data descriptors (with __set__) take priority over instance __dict__
•Non-data descriptors (only __get__) are overridden by instance __dict__
•__set_name__ (Python 3.6+) provides the attribute name to the descriptor

Gotchas

•Descriptors must be class attributes, not instance attributes
•Data descriptors override instance __dict__; non-data descriptors don't
•Accessing descriptor on the class (not instance) passes obj=None to __get__
•property, classmethod, staticmethod, and functions are all descriptors

Descriptors customize attribute access via __get__/__set__/__delete__ on class attributes. Data descriptors (with __set__) override instance __dict__. Powers property, methods, and classmethod.

•Descriptors must be class attributes
•Data descriptors override instance __dict__

class Positive:
    def __set_name__(self, owner, name):
        self.name = f"_{name}"
    def __get__(self, obj, objtype=None):
        return getattr(obj, self.name, None)
    def __set__(self, obj, value):
        if value < 0: raise ValueError("Must be positive")
        setattr(obj, self.name, value)

class Item:
    price = Positive()
    def __init__(self, price):
        self.price = price  # triggers descriptor

print(Item(10).price)  # 10

Instance-level descriptors don't trigger the protocol

Question 11 / 15

How does `del` work, and why should you avoid relying on it?

__del__ is called when an object is about to be garbage collected (its reference count drops to zero or the garbage collector runs). It's a finalizer, not a destructor in the C++ sense.

Why you should avoid relying on it:

Timing is unpredictable: You don't know when (or if) __del__ will be called
May not be called at all: During interpreter shutdown, __del__ may be skipped
Can resurrect objects: If __del__ creates a new reference to the object, it prevents garbage collection
Interferes with garbage collection: Objects with __del__ in reference cycles may not be collected (Python 3.4 fixed this via PEP 442)
Exception handling: Exceptions in __del__ are ignored (only printed to stderr)

Use instead: Context managers (with statement) for deterministic cleanup, or weakref.finalize() for callback-based cleanup.

Pseudo Code

1. __del__ called when reference count reaches 0
2. Timing is non-deterministic
3. May not run during interpreter shutdown
4. Exceptions are silently swallowed
5. Better alternatives: context managers, weakref.finalize()

Code

import weakref

# __del__ basic usage (unreliable)
class Resource:
    def __init__(self, name):
        self.name = name
        print(f"Creating {name}")

    def __del__(self):
        print(f"Destroying {self.name}")

# Explicit deletion triggers __del__ (when refcount hits 0)
r = Resource("R1")  # Creating R1
del r                # Destroying R1 (usually, if no other references)

# But timing is not guaranteed
r2 = Resource("R2")
r3 = r2  # another reference
del r2   # __del__ NOT called -- r3 still references the object
del r3   # NOW __del__ is called

# BETTER: Use context managers for deterministic cleanup
class ManagedResource:
    def __init__(self, name):
        self.name = name

    def __enter__(self):
        print(f"Acquiring {self.name}")
        return self

    def __exit__(self, *args):
        print(f"Releasing {self.name}")  # always called
        return False

with ManagedResource("connection") as res:
    print(f"Using {res.name}")
# Acquiring connection
# Using connection
# Releasing connection  <-- deterministic!

# BETTER: Use weakref.finalize for reliable cleanup
class CleanResource:
    def __init__(self, name):
        self.name = name
        self._finalizer = weakref.finalize(self, self._cleanup, name)

    @staticmethod
    def _cleanup(name):
        print(f"Cleanup: {name}")

    def close(self):
        self._finalizer()  # explicit cleanup

r = CleanResource("DB")
del r  # Cleanup: DB (via finalizer)

# Why __del__ is problematic with reference cycles
class Node:
    def __init__(self, value):
        self.value = value
        self.next = None

    def __del__(self):
        print(f"Deleting Node({self.value})")

# Circular reference
a = Node(1)
b = Node(2)
a.next = b
b.next = a  # cycle!
del a, b
# In CPython with PEP 442, __del__ will eventually be called
# but timing depends on the cyclic garbage collector

Creating R1
Destroying R1
Creating R2
Destroying R2
Acquiring connection
Using connection
Releasing connection
Cleanup: DB
Deleting Node(1)
Deleting Node(2)

Key Points

•__del__ is called when garbage collected, not when del is used
•Timing is non-deterministic and may not happen at all
•Use context managers (with) for deterministic cleanup
•Use weakref.finalize() as a more reliable alternative

Gotchas

•Exceptions in __del__ are printed to stderr and ignored
•__del__ can prevent garbage collection of reference cycles
•Creating new references in __del__ 'resurrects' the object
•During interpreter shutdown, global variables may already be None

__del__ is called during garbage collection but timing is unpredictable. Avoid relying on it. Use context managers for deterministic cleanup, or weakref.finalize() for callbacks.

•__del__ timing is unpredictable
•Use context managers for cleanup

# Avoid __del__ -- use context managers instead
class SafeResource:
    def __enter__(self):
        print("Acquired")
        return self
    def __exit__(self, *args):
        print("Released")  # always runs
        return False

with SafeResource():
    print("Using resource")
# Acquired -> Using resource -> Released (deterministic)

Acquired
Using resource
Released

__del__ may not run at all during interpreter shutdown

Question 12 / 15

How does operator overloading work in Python with dunder methods?

Operator overloading in Python works by implementing specific dunder methods. Each operator maps to one or more dunder methods:

Arithmetic: +(__add__), -(__sub__), *(__mul__), /(__truediv__), //(__floordiv__), %(__mod__), **(__pow__)

Reflected: __radd__, __rsub__, etc. -- called when the left operand doesn't support the operation

In-place: __iadd__, __isub__, etc. -- called for +=, -=, etc.

Unary: __neg__(-), __pos__(+), __abs__(abs), __invert__(~)

Comparison: __eq__, __lt__, __gt__, __le__, __ge__

Bitwise: __and__(&), __or__(|), __xor__(^), __lshift__(<<), __rshift__(>>)

Always return NotImplemented when the operation is not supported for the given types.

Pseudo Code

a + b -> a.__add__(b), or b.__radd__(a) if NotImplemented
a += b -> a.__iadd__(b), or a = a.__add__(b)
-a -> a.__neg__()
abs(a) -> a.__abs__()
a & b -> a.__and__(b)
a[i] -> a.__getitem__(i)

Code

import math

class Matrix:
    """Simple 2x2 matrix with operator overloading."""
    def __init__(self, data):
        self.data = [list(row) for row in data]
        self.rows = len(data)
        self.cols = len(data[0])

    def __add__(self, other):
        if isinstance(other, Matrix):
            if self.rows != other.rows or self.cols != other.cols:
                raise ValueError("Matrix dimensions must match")
            result = [
                [self.data[i][j] + other.data[i][j] for j in range(self.cols)]
                for i in range(self.rows)
            ]
            return Matrix(result)
        return NotImplemented

    def __mul__(self, scalar):
        if isinstance(scalar, (int, float)):
            result = [
                [self.data[i][j] * scalar for j in range(self.cols)]
                for i in range(self.rows)
            ]
            return Matrix(result)
        return NotImplemented

    def __rmul__(self, scalar):
        return self.__mul__(scalar)

    def __neg__(self):
        return self * -1

    def __eq__(self, other):
        if not isinstance(other, Matrix):
            return NotImplemented
        return self.data == other.data

    def __repr__(self):
        rows = ", ".join(str(row) for row in self.data)
        return f"Matrix([{rows}])"

# Usage
m1 = Matrix([[1, 2], [3, 4]])
m2 = Matrix([[5, 6], [7, 8]])

print(m1 + m2)   # Matrix([[6, 8], [10, 12]])
print(m1 * 2)    # Matrix([[2, 4], [6, 8]])
print(3 * m1)    # Matrix([[3, 6], [9, 12]])  -- __rmul__
print(-m1)       # Matrix([[-1, -2], [-3, -4]])  -- __neg__

# Bitwise operators example
class Permissions:
    def __init__(self, flags=0):
        self.flags = flags

    def __or__(self, other):
        if isinstance(other, Permissions):
            return Permissions(self.flags | other.flags)
        return NotImplemented

    def __and__(self, other):
        if isinstance(other, Permissions):
            return Permissions(self.flags & other.flags)
        return NotImplemented

    def __contains__(self, flag):
        return bool(self.flags & flag)

    def __repr__(self):
        return f"Permissions(0b{self.flags:08b})"

READ = Permissions(0b001)
WRITE = Permissions(0b010)
EXEC = Permissions(0b100)

user_perms = READ | WRITE  # __or__
print(user_perms)  # Permissions(0b00000011)
print(0b001 in user_perms)  # True (has READ)

Matrix([[6, 8], [10, 12]])
Matrix([[2, 4], [6, 8]])
Matrix([[3, 6], [9, 12]])
Matrix([[-1, -2], [-3, -4]])
Permissions(0b00000011)
True

Key Points

•Each Python operator maps to specific dunder methods
•__radd__ handles reversed operands, __iadd__ handles +=
•Return NotImplemented for unsupported types
•Bitwise operators (&, |, ^) also have dunder methods

Gotchas

•Don't raise TypeError -- return NotImplemented and let Python handle it
•In-place operators (__iadd__) should modify self and return self for mutables
•If subclass B defines __radd__, it takes priority over parent A's __add__
•Matrix multiplication uses __matmul__ (@) since Python 3.5

Each operator has a dunder method (+ = __add__, - = __sub__, etc.). __radd__ for reversed operands, __iadd__ for +=. Return NotImplemented for unsupported types.

•Operators map to dunder methods
•__rmul__ handles scalar * object

class Vec:
    def __init__(self, x, y):
        self.x, self.y = x, y
    def __add__(self, o):
        return Vec(self.x + o.x, self.y + o.y)
    def __mul__(self, s):
        return Vec(self.x * s, self.y * s)
    def __rmul__(self, s):
        return self * s
    def __repr__(self):
        return f"Vec({self.x}, {self.y})"

print(Vec(1,2) + Vec(3,4))  # Vec(4, 6)
print(3 * Vec(1,2))         # Vec(3, 6)

Vec(4, 6)
Vec(3, 6)

Return NotImplemented, not TypeError

Question 13 / 15

How do `format` and `index` work?

__format__ controls how an object is formatted when used with format(), f-strings, and str.format(). It receives a format spec string (the part after : in format strings).

__index__ returns an integer that represents the object. It's used when Python needs an exact integer: for indexing (seq[obj]), slicing, bin(), oct(), hex(), and operator.index(). Unlike __int__, __index__ must return an exact integer (not a float-to-int conversion).

__format__ is called by the format() built-in and f-strings. If not defined, Python falls back to str(obj) with the format spec applied to that string.

Pseudo Code

__format__(self, format_spec):
  - f'{obj:spec}' calls obj.__format__(spec)
  - format(obj, spec) calls obj.__format__(spec)
  - format_spec is the string after ':' (e.g., '.2f', '>10s')

__index__(self):
  - Returns exact integer for indexing/slicing
  - Used by bin(), oct(), hex()
  - Must return int

Code

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

    def __format__(self, format_spec):
        if format_spec == "f":  # Fahrenheit
            return f"{self.celsius * 9/5 + 32:.1f}F"
        elif format_spec == "k":  # Kelvin
            return f"{self.celsius + 273.15:.1f}K"
        elif format_spec == "":
            return f"{self.celsius:.1f}C"
        # Delegate numeric formatting to float
        return format(self.celsius, format_spec)

t = Temperature(100)
print(f"{t}")       # 100.0C (default)
print(f"{t:f}")     # 212.0F (Fahrenheit)
print(f"{t:k}")     # 373.1K (Kelvin)
print(f"{t:.2f}")   # 100.00 (delegated to float format)
print(format(t, "f"))  # 212.0F

# __index__ example
class Weekday:
    NAMES = ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]

    def __init__(self, day):
        self.day = day  # 0-6

    def __index__(self):
        return self.day

    def __repr__(self):
        return f"Weekday({self.NAMES[self.day]})"

monday = Weekday(0)
wednesday = Weekday(2)

# Used for indexing
letters = ['a', 'b', 'c', 'd', 'e', 'f', 'g']
print(letters[monday])     # 'a' (__index__ returns 0)
print(letters[wednesday])  # 'c' (__index__ returns 2)

# Used for bin/oct/hex
print(bin(wednesday))  # 0b10
print(hex(Weekday(5))) # 0x5

# Used for slicing
print(letters[monday:wednesday])  # ['a', 'b']

# Used with range
for i in range(monday, wednesday):
    print(i)  # 0, 1

100.0C
212.0F
373.1K
100.00
212.0F
a
c
0b10
0x5
['a', 'b']
0
1

Key Points

•__format__ controls f-string and format() behavior with custom format specs
•__index__ returns exact int for indexing, slicing, bin/oct/hex
•__format__ receives the spec string after ':' in format expressions
•__index__ is different from __int__ -- it must return exact integer

Gotchas

•__format__ with empty spec should produce same result as __str__
•__index__ must return int (not float) or TypeError is raised
•Not implementing __format__ falls back to str(obj) with format spec
•__int__ is for int() conversion, __index__ is for exact integer contexts

__format__ controls formatting in f-strings (f'{obj:spec}'). __index__ returns an exact int for indexing and bin()/hex().

•__format__ receives the format spec string
•__index__ for indexing and bin/oct/hex

class Temp:
    def __init__(self, c):
        self.c = c
    def __format__(self, spec):
        if spec == 'f':
            return f"{self.c * 9/5 + 32:.1f}F"
        return f"{self.c:.1f}C"

t = Temp(100)
print(f"{t}")    # 100.0C
print(f"{t:f}")  # 212.0F

100.0C
212.0F

__format__ with empty spec should match __str__

Question 14 / 15

How do you make a class work as a dictionary (mapping protocol)?

To make a class behave like a dictionary, implement the mapping protocol:

__getitem__(self, key): Access by key (obj[key])
__setitem__(self, key, value): Assign by key (obj[key] = value)
__delitem__(self, key): Delete by key (del obj[key])
__len__(self): Number of items (len(obj))
__contains__(self, key): Key membership (key in obj)
__iter__(self): Iterate over keys (for key in obj)
keys(), values(), items(): Dict-like methods

For full compatibility, inherit from collections.abc.MutableMapping and implement __getitem__, __setitem__, __delitem__, __len__, and __iter__. The ABC provides the rest (keys, values, items, get, pop, update, etc.) for free.

Pseudo Code

Minimal mapping: __getitem__, __setitem__, __delitem__, __len__, __iter__
Inherit MutableMapping to get free methods:
  keys(), values(), items(), get(), pop(), update(), __contains__, __eq__

Code

from collections.abc import MutableMapping

class CaseInsensitiveDict(MutableMapping):
    """Dict that treats keys as case-insensitive."""

    def __init__(self, data=None, **kwargs):
        self._store = {}  # lowercase_key -> (original_key, value)
        if data:
            self.update(data)
        if kwargs:
            self.update(kwargs)

    def __getitem__(self, key):
        return self._store[key.lower()][1]

    def __setitem__(self, key, value):
        self._store[key.lower()] = (key, value)

    def __delitem__(self, key):
        del self._store[key.lower()]

    def __iter__(self):
        return (original_key for original_key, _ in self._store.values())

    def __len__(self):
        return len(self._store)

    def __repr__(self):
        items = ", ".join(f"{k!r}: {v!r}" for k, v in self.items())
        return f"CaseInsensitiveDict({{{items}}})"

# Usage
d = CaseInsensitiveDict({"Content-Type": "application/json"})

# Case-insensitive access
print(d["content-type"])   # application/json
print(d["CONTENT-TYPE"])   # application/json
print(d["Content-Type"])   # application/json

# All MutableMapping methods work for free
d["Accept"] = "text/html"
print(len(d))              # 2
print("accept" in d)       # True (case-insensitive)
print(d.get("missing", "default"))  # default
print(list(d.keys()))      # ['Content-Type', 'Accept']
print(list(d.values()))    # ['application/json', 'text/html']
print(list(d.items()))     # [('Content-Type', 'application/json'), ...]

# pop, update, etc. all work
d.update({"Authorization": "Bearer token"})
print(d.pop("authorization"))  # Bearer token

# isinstance check
from collections.abc import Mapping
print(isinstance(d, Mapping))          # True
print(isinstance(d, MutableMapping))   # True

application/json
application/json
application/json
2
True
default
['Content-Type', 'Accept']
['application/json', 'text/html']
[('Content-Type', 'application/json'), ('Accept', 'text/html')]
Bearer token
True
True

Key Points

•Implement __getitem__, __setitem__, __delitem__, __len__, __iter__
•Inherit MutableMapping to get keys(), values(), items(), get(), pop() for free
•Minimal effort for full dict compatibility
•isinstance(obj, Mapping) works automatically

Gotchas

•__getitem__ should raise KeyError for missing keys (not return None)
•Without MutableMapping, you must implement all methods manually
•Remember to handle **kwargs unpacking if needed (__getitem__ + __iter__ + __len__)
•MutableMapping.update() calls your __setitem__ -- make sure it's correct

Inherit MutableMapping and implement __getitem__, __setitem__, __delitem__, __len__, __iter__. You get keys(), values(), items(), get(), pop() for free.

•5 methods for full dict behavior via MutableMapping
•Free methods: keys, values, items, get, pop, update

from collections.abc import MutableMapping

class MyDict(MutableMapping):
    def __init__(self):
        self._data = {}
    def __getitem__(self, key):
        return self._data[key]
    def __setitem__(self, key, val):
        self._data[key] = val
    def __delitem__(self, key):
        del self._data[key]
    def __iter__(self):
        return iter(self._data)
    def __len__(self):
        return len(self._data)

d = MyDict()
d["x"] = 1
print(d.get("x"))  # 1 -- free from MutableMapping

__getitem__ must raise KeyError for missing keys

Question 15 / 15

What is `slots` and how does it affect dunder method behavior?

__slots__ declares fixed instance attributes, preventing the creation of __dict__. This has several effects on dunder methods and behavior:

Memory: No __dict__ means significantly less memory per instance
Speed: Attribute access uses descriptors with fixed offsets, slightly faster
No dynamic attributes: Only attributes listed in __slots__ can be set
Descriptor-based: Each slot creates a descriptor on the class
Inheritance: Subclasses need their own __slots__ for new attributes
Weakref: Not supported unless '__weakref__' is in __slots__
__dict__: Not available unless '__dict__' is in __slots__

__slots__ interacts with several dunder methods: __getattribute__, __setattr__, __delattr__ all respect slot descriptors, which are data descriptors and therefore take priority over instance __dict__ (if both exist).

Pseudo Code

1. __slots__ = ('x', 'y') -> no __dict__, only x and y attributes
2. Each slot is a data descriptor on the class
3. obj.z = 1 raises AttributeError if z not in __slots__
4. Saves ~50% memory per instance
5. Subclass must declare __slots__ for new attributes

Code

import sys

# Memory comparison
class WithDict:
    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

class WithSlots:
    __slots__ = ('x', 'y', 'z')

    def __init__(self, x, y, z):
        self.x = x
        self.y = y
        self.z = z

# Memory per instance
d = WithDict(1, 2, 3)
s = WithSlots(1, 2, 3)

dict_size = sys.getsizeof(d) + sys.getsizeof(d.__dict__)
slots_size = sys.getsizeof(s)
print(f"With __dict__: {dict_size} bytes")
print(f"With __slots__: {slots_size} bytes")

# No dynamic attributes
try:
    s.w = 4  # AttributeError
except AttributeError as e:
    print(e)  # 'WithSlots' object has no attribute 'w'

# No __dict__
print(hasattr(s, '__dict__'))  # False
print(hasattr(d, '__dict__'))  # True

# Slots with inheritance
class Point2D:
    __slots__ = ('x', 'y')

    def __init__(self, x, y):
        self.x = x
        self.y = y

class Point3D(Point2D):
    __slots__ = ('z',)  # only declare NEW slots

    def __init__(self, x, y, z):
        super().__init__(x, y)
        self.z = z

p3 = Point3D(1, 2, 3)
print(p3.x, p3.y, p3.z)  # 1 2 3
print(hasattr(p3, '__dict__'))  # False

# Slots are descriptors on the class
print(type(Point2D.__dict__['x']))  # <class 'member_descriptor'>

# Dunder methods work normally with __slots__
class Vector:
    __slots__ = ('x', 'y')

    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __add__(self, other):
        return Vector(self.x + other.x, self.y + other.y)

    def __repr__(self):
        return f"Vector({self.x}, {self.y})"

    def __eq__(self, other):
        if not isinstance(other, Vector):
            return NotImplemented
        return self.x == other.x and self.y == other.y

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

v1 = Vector(1, 2)
v2 = Vector(3, 4)
print(v1 + v2)  # Vector(4, 6)
print({v1, v1 + v2})  # {Vector(1, 2), Vector(4, 6)}

With __dict__: 344 bytes
With __slots__: 56 bytes
'WithSlots' object has no attribute 'w'
False
True
1 2 3
False
<class 'member_descriptor'>
Vector(4, 6)
{Vector(4, 6), Vector(1, 2)}

Key Points

•__slots__ prevents __dict__, saving memory
•Only declared attributes allowed -- no dynamic attributes
•Slots are data descriptors on the class
•Dunder methods work normally with __slots__

Gotchas

•Cannot use __dict__ for introspection unless __dict__ is in __slots__
•Subclass without __slots__ gets __dict__ back, negating savings
•Cannot pickle slots by default -- need custom __getstate__/__setstate__
•Multiple inheritance with different __slots__ is problematic

__slots__ declares fixed attributes, preventing __dict__ creation. Saves memory, prevents dynamic attributes. Dunder methods work normally with slots.

•Saves memory, prevents dynamic attributes
•Dunder methods unaffected by __slots__

class Point:
    __slots__ = ('x', 'y')
    def __init__(self, x, y):
        self.x, self.y = x, y
    def __repr__(self):
        return f"Point({self.x}, {self.y})"

p = Point(1, 2)
print(p)              # Point(1, 2)
# p.z = 3             # AttributeError
print(hasattr(p, '__dict__'))  # False

Point(1, 2)
False

Subclass without __slots__ reintroduces __dict__

Built by onllm.dev

Home GitHub Support awesomePrep

What is the difference between `__repr__` and `__str__`, and when is each called?

How do `__eq__` and `__hash__` work together, and what are the rules?

How do comparison dunder methods work, and what is `@total_ordering`?

How do arithmetic dunder methods like `__add__` and `__radd__` work?

How do `__len__`, `__getitem__`, `__setitem__`, and `__contains__` make a class behave like a sequence?

How does the `__call__` method work, and when would you use it?

How do `__enter__` and `__exit__` implement the context manager protocol?

How do `__iter__` and `__next__` implement the iterator protocol?

How does `__bool__` work, and what determines the truthiness of an object?

What is the descriptor protocol (`__get__`, `__set__`, `__delete__`)?

How does `__del__` work, and why should you avoid relying on it?

How does operator overloading work in Python with dunder methods?

How do `__format__` and `__index__` work?

How do you make a class work as a dictionary (mapping protocol)?

What is `__slots__` and how does it affect dunder method behavior?

Magic/Dunder Methods & Protocols

What is the difference between `repr` and `str`, and when is each called?

How do `eq` and `hash` work together, and what are the rules?

How do arithmetic dunder methods like `add` and `radd` work?

How do `len`, `getitem`, `setitem`, and `contains` make a class behave like a sequence?

How does the `call` method work, and when would you use it?

How do `enter` and `exit` implement the context manager protocol?

How do `iter` and `next` implement the iterator protocol?

How does `bool` work, and what determines the truthiness of an object?

What is the descriptor protocol (`get`, `set`, `delete`)?

How does `del` work, and why should you avoid relying on it?

How do `format` and `index` work?

What is `slots` and how does it affect dunder method behavior?