Fluent Python

1The iceberg: the Python Data Model

Why len(obj) and not obj.len()? Why does obj[key] trigger __getitem__? Because Python rests on a contract: the special methods (the "dunders": __len__, __getitem__...) that the interpreter calls for you. "The iceberg is called the Python Data Model, and it is the API that we use to make our own objects play well with the most idiomatic language features" (p. 3). Implement the right dunders, and your object works with len(), for, in, slicing — without inheritance, without declared interfaces.

And why isn't len() a method? Raymond Hettinger's answer, quoted in the book: for built-in types, CPython reads a C struct field directly, with no method call — no dispatch overhead. "Practicality beats purity." The whole book flows from that logic: the language favors consistent practicality over theoretical purity.

2Two methods, six capabilities for free

The opening example, FrenchDeck, is a 52-card deck in 15 lines. It implements only __len__ and __getitem__. Two methods, six capabilities for free:

• len(deck) — size
• deck[0], deck[-1] — indexing
• deck[12::13] — slicing (the four aces)
• for card in deck — iteration
• card in deck — membership test
• sorted(deck, key=…) — sorting

No inheritance, no declared interface. That's the return on investment of the Data Model: implement the contract, the language does the rest.

class FrenchDeck:
    def __len__(self):
        return len(self._cards)
    def __getitem__(self, position):
        return self._cards[position]

>>> len(deck)        # 52
>>> deck[12::13]     # the four aces
>>> Card('Q', 'hearts') in deck   # True

3Variables are labels, not boxes

The most common Python trap comes from a wrong mental image. "The b = a statement does not copy the contents of box a into box b. It attaches the label b to the object that already has the label a" (p. 203). Hence chapter 6's HauntedBus: a mutable default parameter (def __init__(self, passengers=[])) is created once and shared by every instance built without arguments. Ghost passengers from one bus haunt all the buses created without passengers.

4Closures: the function carries its environment

A closure is a function that "carries with it" the variables of the place where it was born, even after that place is gone. The book's example, a running average:

def make_averager():
    series = []                       # local variable of make_averager…
    def averager(value):
        series.append(value)          # …yet averager still reaches it
        return sum(series) / len(series)
    return averager

avg = make_averager()
avg(10); avg(20)                      # 15.0 — series survived between calls

"A function that retains the bindings of the free variables that exist when it is defined" (p. 314). The trap the book takes apart: series.append(...) works (you mutate the list), but count += 1 would crash, because reassigning makes the variable local and hides the capture. The nonlocal count keyword exists exactly to say "no, keep the variable from above".

5Decorators and their two timelines

A decorator is target = decorate(target), nothing more: a function that wraps another to add behavior. The book's showcase, memoization in one line:

@functools.cache                 # one single line added above
def fibonacci(n):
    return n if n < 2 else fibonacci(n-1) + fibonacci(n-2)

# fibonacci(30): 832,040 calls → 31. 12 seconds → 0.0002 seconds.

Chapter 9 also installs a distinction that changes how you read code: the decorator runs at import (when Python reads the file), the decorated function only when called. That gap is what lets a decorator register a function in a table at load time, before it is ever called.

6Duck typing, goose typing: the Typing Map

Since Python 3.8 there are four ways to think about interfaces, mapped along two axes: runtime vs static checking, structural vs name-based typing:

• Duck typing — the object has the method, so it works. No declaration. A class with a single __getitem__ is iterable. Use for scripts and internal code.
• Goose typing — ABCs + isinstance. Explicit registration, runtime checks. Use when callers need a guarantee at runtime.
• Static typing — Java-style type hints, checked by mypy/pyright. Use for large codebases and public APIs.
• Static duck typing — typing.Protocol, Go's approach: structural matching checked statically, without inheritance. Use for public libraries that shouldn't force ABCs on callers.

The book's verdict: these four approaches are complementary, none deserves to be dismissed (p. 432). The map is there to help you choose deliberately — not to pick a camp.

7yield: the Iterator pattern built into the language

When data doesn't fit in memory, you need to produce items one at a time, on demand. Any function containing yield becomes a generator: it computes nothing until you ask for the next value.

def read_lines(path):
    with open(path) as f:
        for line in f:
            yield line.strip()       # one line at a time, never all in RAM

for line in read_lines('file_50gb.log'):    # works with a few KB of memory
    process(line)

A vocabulary precision the book hammers: a function returns a value and dies; a generator yields values and pauses between each, resuming exactly where it left off. Where Java codes the Iterator design pattern by hand, Python built it into the language with this one keyword.

8The GIL, explained in ten points

Chapter 19 defuses Python's most misunderstood topic: only one Python thread executes at a time, regardless of CPU cores. But every function that makes a syscall (disk I/O, network, time.sleep) releases the GIL. Consequence: Python threads are excellent at waiting ("Python threads are great at doing nothing", David Beazley, quoted p. 700) and useless for computation.

A lesser-known detail from point 6: many CPU-intensive NumPy/SciPy functions and the zlib/bz2 compressors also release the GIL, which is why threaded scientific computing can work. For CPU-intensive pure Python: multiple processes.