Overview

Imperative code is an explicit sequence of statements that change state step by step -- a loop that mutates a counter, an assignment that overwrites a variable. It maps directly onto how a CPU actually executes instructions, which makes it predictable to trace one line at a time -- but nothing stops a later statement from silently depending on state set several lines earlier (Example 1's mutating word-count loop; Example 33's turnstile modeled as a mutable state variable).

The underlying execution model stays 100% imperative -- tokenize() and tally() are still just as mutating internally. What changes is that the logic now has a name, a boundary, and an independent test surface, so main() shrinks to a readable sequence of calls (Example 2's tokenize()/tally() refactor; Example 27's procedural area_via_tag()).

A goto-shaped jump (in Python, usually a boolean flag standing in for a jump target) can transfer control from anywhere to anywhere, so understanding one line can require understanding the whole program. Sequence, selection, and iteration each have exactly one entry and one exit, so a reader can understand a block by reading its own lines, never hunting for where control jumped in from (Example 3 replaces a boolean goto flag with if/elif/else; Example 26 flattens a nested-if pyramid into guard clauses).

Rebinding (x = 20) points a name at a new object; mutating through an alias (alias.append(4)) changes the SAME object every name pointing at it can see. An aliased mutable object can be changed by code that has no visible connection to the code reading it later -- two names, one box (Example 4 demonstrates both directly; Example 53 dispatches transitions off a plain enum.Enum).

Every method on a class has guaranteed access to that instance's own data without it being passed in separately, and two instances of the same class never share state by accident. That isolation is what makes encapsulation (co-06) possible in the first place (Example 6's WordCounter class; Example 30's OO leg of the four-paradigm comparison).

When every mutation is forced through deposit()/withdraw(), those methods become the ONLY place an invariant (balance never negative) can be broken -- which means they're also the only place it needs to be checked, tested, and trusted. Direct field access scatters that responsibility across every caller instead (Example 7's BankBalance guards its invariant, and a rejected withdrawal is shown to leave it intact).

Structural typing (a Protocol) means the caller only needs to know the message SHAPE, never the concrete class receiving it -- each receiver decides for itself how to respond. This is what makes polymorphic dispatch work: the same call site produces different behavior depending purely on which object receives the message at runtime (Example 8 sends speak() to an unrelated Duck and Dog).

Declarative code hands the "how" to the language or engine, so the reader only verifies the "what" -- there's no accumulator variable or loop index to trace. The cost is that the "how" becomes opaque; you trust the engine (a comprehension, a rules table, a SQL planner) to do it correctly (Example 9's comprehension vs. loop; Example 54's declarative validation rules table).

A function that only reads its arguments and returns a new value is safe to call twice, safe to call from multiple threads, and easy to test in isolation -- no setup beyond the arguments is ever needed (Example 11's Counter/reduce word count with no visible mutation; Example 64's state rebuilt by folding an event log).

An expression composes -- it can be passed as an argument, embedded in a larger expression, or returned directly -- while a statement can only be executed for its effect. Chaining expressions is a large part of what makes declarative code read as one flowing computation rather than a sequence of steps (Example 12 contrasts a conditional expression against an if/assign block; Example 44's lazy pipeline is built entirely from composed expressions).

A pure function called twice with the same argument always produces the same result and touches nothing else -- it can be reasoned about, cached, and reused without knowing its calling context. Any hidden effect (appending to a log, mutating an argument) breaks that guarantee even if the return value looks identical (Example 13 contrasts normalize() against normalize_and_log(); Example 67 refactors a mutation-heavy routine into a pure fold).

Behavior itself becomes a parameter -- the same apply_all(fn, items) helper can double every item, square every item, or apply an arbitrary lambda, all without apply_all's own code changing at all. This is the seed that grows into decorators, callbacks, and strategy objects (Example 14 passes double, square, and a lambda into the same helper).

In a logic program you state relationships (facts and rules) and ask questions; the engine's search finds answers you never explicitly computed -- "who is Alice's grandchild" was never stored anywhere, yet the query resolves it (Example 19 infers a grandparent relationship via composed facts; Example 60 builds a mini backtracking engine resolving a transitive-closure query).

Backtracking means: try a candidate binding, recurse deeper, and if that path fails, UNDO the choice before trying the next candidate. Skip the undo and a rejected choice leaks into sibling branches that never should have seen it, producing a wrong or oversized result (Example 37's N-Queens is_safe()/backtrack() pair; Kata 6 reproduces exactly this bug by omitting the pop).

Separating "what must be true" (the declared constraints) from "how to search for it" (the solver) means the same solver reuses across entirely different puzzles -- only the variables, domains, and constraints change (Example 61's generic CSPSolver reused for map coloring and a Latin-square puzzle; Example 71 schedules tasks under precedence constraints).

In you-call-library code, your code decides exactly when things happen; in event-driven code, the framework decides when your handler runs, based on events it observes. You give up control of the timeline in exchange for not writing the loop that watches for events yourself (Example 45 contrasts both control-flow shapes directly; Example 55's typed publish/subscribe bus).

"I changed A but forgot to also update the thing that depends on A" -- reactive propagation makes the dependency wiring itself responsible for keeping derived values current, automatically, every time (Example 17's ObservableValue pushes to subscribers on set(); Example 42 contrasts a manually-maintained derived value that goes stale against the same thing done reactively).

It can find independent nodes and run them in parallel, skip recomputing nodes whose inputs never changed (memoization), and reorder execution freely as long as every edge is respected -- none of which a fixed sequence gives you for free (Example 43 executes a DAG in topological order; Example 57 memoizes dataflow nodes, skipping recompute on an unchanged subtree).

Relational operations (select, project, join) compose freely and are optimizable by a query planner precisely because they're declared as set operations rather than a specific loop order -- the same declared query can run efficiently at any scale, while a hand-written loop's performance is fixed by the loop structure you wrote (Example 15's SQL top-3-words query; Example 47 contrasts a SQL JOIN against an equivalent nested loop).

Python doesn't force a single paradigm -- a genuine strength -- but that also means the discipline of choosing ONE paradigm per boundary (co-25) has to come from the developer, not the language (Example 20 mixes a class, a comprehension, and a generator in one script; Example 78's comparison matrix across every paradigm solution built in this topic).

Each paradigm trades a constraint for a guarantee -- purity buys reasoning, immutability buys safe sharing, encapsulation buys change isolation, declarative style buys optimizability. Naming the specific constraint and the specific property it buys turns "which paradigm should I use" into an engineering question, not a taste question (Example 21 shares a frozen tuple/frozenset and confirms neither function can mutate it).

OO's encapsulated instance state, functional programming's insistence on no shared mutable state, reactive programming's automatic propagation instead of manual mutation -- every one of those distinctions is ultimately a different answer to that same question (Example 22 contrasts a mutable-global running total against an immutable fold; Example 74 reproduces a real data race from shared mutable state under two threads and shows the immutable-design twin has none).

Recognizing the shape a problem already has -- search-and-satisfy fits constraint programming, a UI that must stay synchronized fits reactive, a batch transformation with no shared state fits functional -- and reaching for the paradigm built for that shape, rather than forcing every problem into one default lens (Example 66's decision table; Example 80's final choose-and-defend grounded in this topic's own code).

Every paradigm's benefit is paid for with a specific cost -- readability, testability, or change-cost. A comprehension is fewer lines but hides the "how"; a constraint solver reuses across problems but costs more to write the first time. Every contrast example in this topic is really asking "which cost am I willing to pay here" (Example 58 measures lines-of-code trade-offs directly; Example 79 measures a concrete performance cost of immutability).

Discipline at the boundary: know which side of a function call is "the functional part" and which is "the OO part," and never let a paradigm's guarantee (like "this value can't be mutated") get silently violated by code that only LOOKS like it respects that guarantee (Example 49 crosses a functional-to-OO boundary passing only immutable data; Example 50 reproduces the paradigm-soup failure mode directly -- a mutable object aliased and silently corrupted through a "functional-looking" chain).

This is a structured-programming violation (co-03) -- the flag is a goto-style jump target standing in for a proper exit. Replace it with the specific construct that actually needs to fire: an early return, a break at the point of decision, or a continue scoped to just that iteration, so a reader never has to hunt for where control "jumped in from" (Example 26; Kata 2).

This is a pure-vs-impure boundary problem (co-11) -- the "total" computation and the "log an audit entry" side effect are two different responsibilities wearing one function's name. Split them: a pure compute_total() safe to call any number of times, and an explicit, separately-called log_audit() (Example 13; Kata 1's mutable-default variant of the same "hidden side effect" family).

This is a reactive-programming gap (co-17) -- total (or the displayed count) is stored as a plain field kept "in sync" by hand at every call site that touches items, and one call site was missed. Making the count a computed property (or a subscriber pushed to on every items change) makes it structurally impossible to forget (Example 42; Kata 4).

This is a backtracking violation (co-14) -- a failed branch must undo (pop, unset) its choice before trying the alternative. Without the undo, state from a REJECTED branch leaks into the next branch tried (Example 37's N-Queens; Kata 6 reproduces this exact bug with a missing chosen.pop()).

This is an event-driven-paradigm violation (co-16) -- the dispatch loop iterates a frozen snapshot of the queue taken at loop start, rather than draining the live queue. Replace the snapshot iteration with a while queue: drain so events appended mid-dispatch are also seen (Example 40; Kata 7).

This is a dataflow-programming violation (co-18) -- a memoized node must be invalidated (or its staleness detected) whenever a dependency it's declared to depend on actually changes; caching once and never checking again silently breaks the "recompute on change" contract dataflow depends on (Example 57's correctly-memoized nodes; Kata 8 reproduces the stale-cache bug directly).

This is state-as-the-fault-line (co-22) -- a shared mutable cell's read-modify-write is not atomic, so two threads can interleave and lose an update. The fix is not a bigger lock budget; it's removing the shared mutable target entirely: give each thread its own private slot and combine with a pure fold only after every thread finishes (Example 74; Kata 9).

This is paradigm soup (co-25) -- somewhere in the chain a closure captures and mutates state that outlives a single call (a module-level list, a mutable default argument), so calling the SAME pipeline twice with the SAME input produces different results. A genuinely pure pipeline depends only on its own arguments, nothing else (Example 50; Kata 10).

This calls for constraint programming (co-15) -- declare the precedence and single-resource-per-day rules as constraints and hand them to a generic solver, instead of hand-encoding the search as nested loops. A new rule becomes "add a constraint," not "add another special-case if to an already-deep loop nest" (Example 61's generic CSPSolver; Example 71's task scheduling).

This is paradigm cost ignored (co-24), and specifically the "choose the paradigm whose grain fits the problem" skill (co-23) applied backwards -- the script's actual shape (read, sum, print, done) needs no paradigm machinery at all. Naming a pattern's benefit without weighing its cost against a problem this small is exactly the mistake co-24 warns about (Example 28's explicit "paradigm choice is noise" case).

Root cause: Python evaluates a default argument expression exactly ONCE, at function-definition time -- not once per call. [] is created a single time and every call that omits words receives that SAME list object. The fix uses None as a sentinel and constructs a genuinely fresh [] inside the body, on every call.

Run: python3 kata.py

Output:

['alpha']
['beta']

Root cause: skip is a variable that outlives the single iteration it was meant to govern -- a goto-style stand-in for "jump past this one order" that structured programming's single-entry/single- exit constructs make unnecessary. A continue scoped to the current iteration expresses the SAME intent without any state that can leak into later iterations.

Run: python3 kata.py

Output:

['A', 'C']

Root cause: a public field is an open door -- ANY code with a reference to the object can mutate it without going through the method that enforces the invariant. Renaming the field _balance and exposing only withdraw()/read() makes the invariant-checking method the ONLY path that can ever change the value.

Run: python3 kata.py

Output:

False
50

Root cause: total was a plain field, so keeping it in sync depended on every mutating method remembering to also update it -- a manual contract with no enforcement. Making total a @property that recomputes from items every time it's read removes the separate field entirely; there is nothing left that could ever go stale.

Run: python3 kata.py

Output:

[20]
20

Root cause: list.sort() mutates its receiver in place and returns None -- calling it on the argument the caller passed in changes THEIR list, not a copy. sorted() builds and returns a brand-new list, leaving the argument completely untouched, which is what makes the function safe to call without worrying about the caller's data.

Run: python3 kata.py

Output:

[1, 2, 3]
[3, 1, 2]

Root cause: chosen.append() mutates a SHARED list across the entire recursive search tree. When an inclusion branch fails, the number appended for that branch is still sitting in chosen when the sibling "exclude" branch runs -- chosen.pop() is what removes it, restoring chosen to exactly the state it had before the rejected choice was tried.

Run: python3 kata.py

Output:

[2]

Root cause: list(queue) copies the queue's CURRENT contents once, at loop start -- the for loop then walks that frozen copy, completely disconnected from any later appends to queue itself. Replacing the snapshot iteration with while queue: event = queue.pop(0) drains the LIVE queue, so an event appended mid-dispatch is picked up on a later trip through the loop.

Run: python3 kata.py

Output:

['signup', 'login', 'welcome_email']

Root cause: _cache is None is the ONLY staleness check, and once the cache is populated it's None never again -- there is no mechanism that notices source changed. Tracking a cheap signal of the dependency's state (here, its length) and recomputing whenever that signal disagrees with what the cache was built for is a minimal, real dataflow "dirty check."

Run: python3 kata.py

Output:

12
32

Root cause: counter.views is one shared mutable cell; a read-then-write is not atomic, and the threading.Event handshake deterministically forces BOTH threads to read the stale value 0 before EITHER writes 1 -- so the second write simply overwrites the first with the same value, and one increment vanishes. The fix removes the shared mutable target entirely: each thread owns a disjoint slot in results, and the two counts are combined with a pure sum() only after both threads have finished -- there is no memory location either thread could ever race on.

Run: python3 kata.py

Output:

2

Root cause: enrich() reads its "how many seen so far" number from module-level _seen_ids, mutated as a side effect of every call, EVER -- across BOTH invocations of build_report(). It looks functional (it's passed to map(), it returns a value) but it is not pure, because its result depends on something other than its own argument. Passing the index explicitly (enumerate) makes the same information available WITHOUT any shared, mutated state.

Run: python3 kata.py

Output:

[1, 2]
[1, 2]

OO's encapsulated instance state, functional programming's insistence on no shared mutable state, and reactive programming's automatic propagation are all, at bottom, different answers to "where does mutable state live, and who's allowed to touch it." Once you can name a design's answer to that one question, you can predict most of its other paradigm-level properties without inspecting anything else.

Comfort is about the DEVELOPER; shape-matching is about the PROBLEM. Forcing a search-and-satisfy problem into hand-written imperative loops doesn't just cost more code -- it actively hides structure the problem already has (a constraint solver would find the feasible space directly). The durable skill is recognizing that shape, independent of which paradigm feels most familiar.

chosen is one shared, mutable list referenced by the entire recursive call tree, not a fresh copy per branch. When an inclusion branch fails and the code falls through to the exclusion branch, the already-appended number is still physically present in chosen -- so the final returned list reflects a combination of "excluded" and "included" choices that never should have coexisted, not merely a slower search.

A real race's timing is non-deterministic because the OS scheduler decides when each thread runs. The Event handshake replaces "hope the scheduler interleaves badly" with an explicit protocol: each thread signals "I have read" and then WAITS for the other thread's signal before writing. That forces the exact interleaving that causes the bug, every single time, which is what makes it teachable and testable rather than a flaky coin flip.

Declarative code hands the "how" to an engine, so the reader only verifies the "what" -- a real readability and correctness win. But that same "how" becomes opaque: a slow SQL query or an unexpectedly expensive comprehension is harder to diagnose precisely because the mechanics are hidden from the code that expresses the intent. Neither style dominates; each is a different bet on what the reader needs to see.

A multi-paradigm language like Python is often at its best mixing paradigms deliberately -- a functional pipeline handing immutable data to an OO service is fine. What makes it soup is a guarantee being silently violated: a "functional-looking" chain that secretly threads a mutable object through every step collects the COSTS of both paradigms (indirection, hidden effects) while delivering the BENEFITS of neither.

Reactive programming's actual goal is eliminating "I changed A but forgot to update the thing that depends on A." A push/subscribe mechanism is ONE way to guarantee that; a computed property that recomputes from source data on every read is a simpler way to guarantee the exact same thing for a value with no independent state of its own. The mechanism differs; the guarantee -- no possible staleness -- is identical.

Once "purity buys reasoning," "immutability buys safe sharing," and "encapsulation buys change isolation" are all instances of the SAME pattern (give up a capability, receive a guarantee), a new, unfamiliar paradigm can be evaluated the same way: what does it force you to give up, and what does it promise in return? That question turns "which paradigm should I use" from a taste question into an engineering one, for paradigms this topic never even names.