Debugging Python: From Symptom to Fix

1. A teammate says: “I added print(repr(x)) and saw the value had a leading space.” Which stage of the debugging cycle is this?

• Hypothesis

  A hypothesis is a one-sentence proposed cause (e.g., “the input has invisible whitespace”). Adding a print and observing a value is the evidence you’d use to test such a hypothesis.

• Evidence collection
• Localize

  Localize is identifying the line where intended and actual diverge. Observing a value reveals what is wrong; localization is the next move (which line first produced this value?).

• Verification

  Verification is rerunning the test suite after a fix. The print(repr(x)) happened before any edit, so it’s earlier in the cycle.

2. A student fixes their failing test, runs pytest test_failing.py (just that one file) and sees green. They mark the bug fixed and move on. What stage did they skip?

• Verification — they should rerun all tests, not only the previously failing one
• Hypothesis — they should have written down their proposed cause first

  Hypothesis is important, but the student got past it — they identified a fix that worked. The skip happened after the fix, when they didn’t rerun the rest of the suite.

• Localization — they should have identified the exact line

  Localization happened — they fixed something. The skip was after the fix, in the verification phase.

• Nothing — running the previously-failing test is sufficient verification

  This is the local-verification trap — judging the whole program by checking only the part you just touched. A fix can break tests that were previously passing, and the only way to catch that is rerunning the whole suite.

3. A debugger user types len(parts) into the Watch panel during a paused session and sees 2, when they expected 3. Which stage of the cycle is this?

• Predict

  Predict happens before the debugger pauses — it’s holding a value in your head. Watching a live value during a pause is collecting evidence against the prediction.

• Evidence
• Localize

  Localize is identifying the line where intended and actual diverge. Watching a value confirms a value is wrong; localization is the next move (which line first produced this value?).

• Verify

  Verify happens after a fix — rerunning the test suite. The student here hasn’t fixed anything yet; they’re still gathering data.

4. total(items) returns $5 too high for one user. You discover the discount-loading function reads the wrong database column, so that user’s discount is never applied. Which is the symptom and which is the cause?

• Symptom: discount-loading reads wrong column. Cause: total is $5 too high.

  This is the canonical symptom-vs-cause swap. Calling the column-read the symptom would push you to “fix” the visible total (if user_id == BAD_USER: total -= 5) — and leave the actual broken function untouched. Every other user who hits the same column read still gets wrong totals; the next column rename will silently break it again. The thing the user experiences is the symptom; the thing in the code that produces it is the cause. Mixing them up is exactly how programs accumulate if BAD_USER patches that no one understands six months later.

• Symptom: total is $5 too high. Cause: discount-loading reads wrong column.
• They are the same thing — the user’s bill is wrong.

  Symptom and cause are different concepts. The symptom is what you observe (a wrong total). The cause is the broken thing that produces the symptom (the wrong column).

• Neither — both are bugs and need separate fixes.

  There is one root cause (the wrong column) producing one symptom (the wrong total). Treating them as separate bugs leads to symptom-patching — e.g., subtracting $5 from the total — without fixing the actual problem.

1. “I want to know which iteration of a 10,000-item loop is the first one to break the invariant.” Which tool answers it?

• Step Over until it breaks

  Stepping through 10,000 iterations works in principle but is prohibitive. A conditional breakpoint runs the same check at every iteration inside the debugger’s engine — effectively free per iteration — and pauses only when the predicate is true.

• Conditional breakpoint with the invariant as the predicate
• Hover over the variable

  Hover shows the value at this paused moment. It can’t filter across iterations.

• Call Stack

  Call Stack shows how you got to the current line, not which iteration first violated something.

2. “I want to inspect what total was 5 lines ago.” Which tool answers it?

• Add a Watch and rerun

  Watch shows the current value at the paused moment, not historical values.

• Drag the History scrubber backward
• Set a breakpoint earlier and restart

  This works but requires re-executing the entire program from scratch. If the program takes 30 seconds — or an hour — to run, you pay that cost every time you want to inspect a different moment. The scrubber rewinds through the recorded trace instantly, no rerun needed.

• Hover the variable

  Hover is the same as Watch — it shows the value at the current pause, not the past.

3. The tour file’s line-14 def enroll(student, students=[]) lights up the ↔ aliasing badge across calls. Why?

• Each call gets its own fresh empty list — the ↔ badge is reporting incorrect state

  The ↔ badge is correct — the bug is real. Try it: run enroll("Ada") twice and the second call’s students already contains “Ada” from the first.

• Default argument values are evaluated once at function-definition time, so every call that uses the default shares one list
• The interpreter caches all empty lists as the same object for memory efficiency

  Python doesn’t intern lists. [] is [] returns False — every literal [] makes a new object. The trap is only with default arguments, because the default expression runs once at def time.

• Python’s parameter passing is by-reference, so mutations leak across calls

  Python is pass-by-reference for objects, but a fresh local variable inside each function call wouldn’t share state across calls. The aliasing here is specifically because the default value object is reused.

1. Which of these would be a root-cause fix for this bug, as opposed to a workaround?

• Change the failing test to use max_steps=11 so it passes

  This makes the test pass without changing the code’s behavior — the same bug would still reject any future user who calls find_path with the exact required budget. That’s a workaround, not a fix.

• Edit BATTERY_LIMIT_MAZE to add an extra row of open cells

  Editing the data makes the bug invisible for this maze. The next maze with a path equal to its budget would have the same problem. That’s a workaround.

• Move the if current == goal: check to run before the cutoff check
• Catch the None return in find_path and re-run DFS with max_steps + 1

  Calling DFS twice is more code, doesn’t address why the first call rejected a valid path, and is twice as slow. The actual bug — wrong check ordering in _dfs — is still present.

2. A student fixes _dfs by loosening the cutoff to steps_used > max_steps instead of swapping the check order. The test_path_found_when_battery_limit_is_exact test now passes. Is this a correct fix?

• Yes — it works for this case, so it is correct

  Making one test pass is not the same as fixing the bug. steps_used > max_steps means the cutoff fires only when steps_used exceeds the budget — so a path of length max_steps + 1 would be accepted. Try the test_path_rejected_when_battery_too_small test with this ‘fix’ applied.

• No — it accepts paths that exceed the budget. test_path_rejected_when_battery_too_small would now fail, because a path longer than max_steps would no longer be rejected.
• Yes — > and >= are interchangeable in boundary checks

  > and >= differ at exactly the boundary value — the very value this bug is about. steps_used >= max_steps rejects steps_used == max_steps; steps_used > max_steps accepts it. They are not interchangeable when the boundary case is the target.

• No — we should have used < instead

  steps_used < max_steps inverts the cutoff entirely, accepting any path that used fewer steps than the budget and rejecting everything at or above. That would reject even the small-maze two-step path.

3. True or false: Once you’ve fixed the boundary bug in _dfs, you can verify the fix is correct by rerunning only test_path_found_when_battery_limit_is_exact (the previously failing test).

• True — the other tests already passed, so they’re fine

  Fixing one test can break another — test_path_rejected_when_battery_too_small is exactly the kind of case a too-aggressive fix could break. The only reliable verification is rerunning the entire suite.

• False — verify means rerun all tests, including the ones that were already green, to catch regressions

1. Which of these is the root-cause fix?

• After reconcile(...) runs, do balances["ACCT-202"] += 3600 to correct the off-by-$36 result

  This hardcodes a one-time correction. The next CSV with the same shape will be wrong again. The bug is that the loader doesn’t normalize whitespace — that’s where the fix belongs.

• Edit transactions.csv to remove the leading space on row T011

  Editing the data hides the symptom for this CSV but doesn’t fix the loader. Real CSV imports often have stray whitespace; a robust loader strips it.

• In load_transactions, change row["type"].upper() to row["type"].strip().upper()
• Change the REVERSAL branch in apply_transaction to subtract instead of add

  This rewrites the spec to match the bug’s symptom. The REVERSAL arithmetic is correct (a reversal cancels a charge — addition). The bug is that the kind field never had a chance to match "REVERSAL".

2. Why is repr(tx.kind) more useful than print(tx.kind) when investigating this bug?

• repr() calls str() internally, so it produces the same output — the difference is just defensive habit

  str(' REVERSAL') outputs the string’s content directly — the leading space looks the same as any gap before a word. repr(' REVERSAL') outputs "' REVERSAL'", wrapping the whole value in quote characters. Those outer quotes make the leading space unmistakable: you can see it sits inside the quotes, between ' and R. The difference is structural, not stylistic.

• repr() shows quotes and escape characters around the string, making invisible characters (like leading spaces) visible
• repr() strips trailing whitespace before displaying, which is what makes the leading space visible by contrast

  Backwards. repr() doesn’t strip whitespace — it displays it inside quote delimiters so you can see it. print() displays the string’s raw content without delimiters, which is precisely what makes leading/trailing whitespace invisible.

• repr() is the only function that displays unicode characters correctly

  Both print() and repr() display Unicode correctly. The issue is that print() outputs raw content without surrounding delimiters, so a leading space looks like normal spacing, while repr() wraps the value in quote characters that make the boundary visible.

3. You have a 30-iteration loop where one specific iteration produces a wrong result. Which technique most efficiently locates the bad iteration?

• Set a normal breakpoint inside the loop and click Continue 30 times

  This works but is exactly the kind of mechanical drudgery the debugger is meant to eliminate. With 30 iterations it’s tolerable; with 30,000 it’s hopeless.

• Set a conditional breakpoint with a predicate that’s true ONLY for the suspicious iteration
• Add print(...) to every line of the function and read the output

  This produces a flood of output you’d have to skim by eye. A conditional breakpoint puts the filtering logic inside the debugger so it stops only on the iteration you care about.

• Comment out lines until the loop produces the right answer

  This is tinkering — random edits to see what changes. It can occasionally land on the answer but it teaches the wrong habit and breaks badly on bigger programs.

1. “I want to find the first event in a 50-event stream that produced a wrong state.” Which scrubber move fits best?

• Step Over forward from the start until something looks wrong

  Forward stepping forces you to inspect early events that produced no symptom. The first 30 events may all be correct; you’d waste attention before reaching the divergence.

• Run to completion, anchor on the wrong final state, scrub backward until the state matches the spec
• Set a conditional breakpoint at the start of the loop

  A conditional breakpoint helps when you can describe the cue in advance (e.g., ‘when count goes negative’). When you only know the final symptom and the cause’s shape is unclear, scrubbing is more direct.

• Hover the variable in the editor

  Hover shows the value at the current paused moment. It can’t move you through history.

2. “What was count after exactly 4 events?” — which scrubber move answers this?

• Drag the scrubber until len(state['history']) shows 4
• Restart and step over 4 times

  This works but requires re-running the program from scratch. The scrubber moves through the recorded trace instantly — no rerun needed.

• Hover count in the editor

  Hover shows the value at the current paused moment, not at a specific past tick.

• Set a breakpoint at line 4

  Line numbers and event counts aren’t the same. A breakpoint on line 4 fires every time line 4 runs — once per iteration — which doesn’t directly answer ‘after 4 events’.

3. After scrubbing backward, the arrow gutter turns gray. What does that mean?

• The program crashed

  A crash would be reported as a traceback, not a UI state change.

• You’re inspecting a past state — not ‘live’ execution. Edits won’t take effect from this rewound point until you scrub forward to the end again
• The debugger has lost the recording

  The recording is intact — gray indicates position, not loss.

• You’ve reached the start of the program

  The scrubber’s leftmost position is the start; gray applies whenever you’re not at the rightmost (live) position.

1. For a Python list xs = ['a', 'b', 'c', 'd'], what does xs.pop() return, and what is xs afterward?

• Returns 'a'; xs becomes ['b', 'c', 'd']

  That would be xs.pop(0), which removes from the front. With no argument, pop() removes from the end.

• Returns 'd'; xs becomes ['a', 'b', 'c']
• Returns the entire list; xs becomes []

  pop removes a single element, not the whole list. For a single-element list, that element happens to be the whole list, but in general only one element is returned.

• Raises an error — pop() requires an index

  pop() works without an argument — it defaults to -1, the last element. pop(0) and pop(-1) are both valid.

2. Which of these is the correct fix to enforce FIFO admission policy?

• Sort course.waitlist alphabetically before calling pop()

  Alphabetical order happens to match FIFO order in this specific test by coincidence (Mina, Theo come before Jules). Change one student’s name and the test breaks. The spec is FIFO (insertion order), not alphabetical — these are different concepts.

• Special-case Jules Kim and Mina Patel in allocate_next

  Hardcoding student names is the textbook symptom-patch anti-pattern. The next event stream with different names breaks again. The bug isn’t about which students; it’s about which end of the list is admitted first.

• Change course.waitlist.pop() to course.waitlist.pop(0) in allocate_next
• Reorder sample_events() so Jules Kim joins last

  Editing the input data to match the bug is a workaround. Real registrar systems can’t reorder real student actions to make their code happy.

3. You discover the symptom (CS201 enrolls the wrong students) at the end of the program, but the cause is in event 4 (drop Ben Ortiz, which triggers allocate_next). Which technique most directly localizes the bug?

• Step from event 1, watching state after each event, until something looks wrong

  Forward stepping works but is wasteful — events 1, 2, 3 produce no symptom. You’d inspect them anyway because you don’t know which event is the bad one until you reach it. Backward navigation lets you anchor on the known wrong final state and rewind to the divergence.

• Set a breakpoint on the failing test’s assertion and inspect the final state

  The final state inspection only confirms the symptom you already knew about (the test failed). It doesn’t help localize which event caused it.

• Run to completion, then drag the History scrubber backward to find the first event where state diverged from the spec
• Add print(state) after every event and read the output

  Adding prints is a viable fallback when no time-travel debugger is available. With one available, scrubbing is faster, leaves no print debris in the code, and lets you skim 9 snapshots in seconds.

4. (Bonus — code communication.) Which choice best communicates that a list is being used as a FIFO queue?

• my_list.pop(0) (Python list)

  pop(0) works but doesn’t tell the next reader “queue” — many lists use pop(0) for non-queue reasons, so intent must be inferred from context. It also costs O(n) time because Python shifts every remaining element left after removing index 0. deque.popleft() communicates intent and runs in O(1).

• my_deque.popleft() (collections.deque)
• my_list[0]; del my_list[0]

  Functionally equivalent but harder to read. popleft() names the operation in one word.

• heapq.heappop(my_heap)

  heapq is a priority queue — it returns the smallest element regardless of insertion order. That’s not FIFO.

1. A function processes 50,000 log lines and produces a wrong total. You’ve confirmed the bug is consistent run-to-run. Which technique most efficiently localizes it?

• Set a normal breakpoint inside the loop and step through, watching the running total

  Stepping through 50,000 iterations is exactly the kind of work the debugger should save you. With a conditional, the debugger pauses only on the iteration of interest.

• Set a conditional breakpoint that pauses only when the running total exceeds the maximum plausible value (or whatever invariant is broken)
• Add print statements after every line in the function and read the 50,000 lines of output

  Reading 50,000 lines by eye is human-impossible. If you must use prints, filter them with a predicate so only the relevant ones print — at which point you’ve reinvented a conditional breakpoint, more clumsily.

• Run with pdb.set_trace() before the loop and step through it manually

  pdb.set_trace() is a real and common move, but it leaves you stepping through 50,000 iterations the same way option 0 does. The debugger has filters; use them.

2. A recursive function returns the wrong answer for one specific input. The function is small (12 lines) and you have a clear test case that reproduces it. Which technique fits best?

• Conditional breakpoint with a complex predicate

  A conditional breakpoint is overkill here — the function is small and the input is specific. An ordinary breakpoint plus stepping plus the call stack gives you everything you need.

• Back-in-time scrubbing of the entire program execution

  Back-in-time scrubbing shines when the symptom appears far from the cause. Here, the function is 12 lines and the symptom is in the return value — it’s not a temporal-distance problem.

• Ordinary breakpoint at the top of the function plus a Watch expression on the parameter and any boundary expression
• Add a print() inside the recursion to trace each call

  Print-tracing works but modifies the source for every probe. Ordinary breakpoints + watches give you the same information non-invasively, and the call stack tells you what print can’t (which recursion path you’re on).

3. Final cart total is wrong; a discount appears to have been applied to the wrong line item. The cart processed 8 events (add item, apply coupon, etc.) and the wrong-line discount happened somewhere in the middle. Which technique fits best?

• Set a conditional breakpoint on the discount-application line that pauses if the wrong line is being modified

  This works if you already know which expression characterizes ‘wrong line.’ Often you don’t — that’s exactly what scrubbing helps you discover. Once scrubbing has identified the suspicious moment, then a breakpoint can pinpoint it.

• Run to completion, then scrub the History scrubber backward to find the first event where the discount went to the wrong line
• Use git bisect on the cart’s commit history

  git bisect finds the commit that introduced a regression. Useful for a different class of debugging problem (a bug that worked before some commit). It’s not the right tool when you have one buggy version and want to know which event in a single run caused the symptom.

• Step forward through every event from the start

  Forward stepping through 8 events is fine in a pinch but wasteful — events 1, 2, 3 likely produced correct partial state. Anchoring on the wrong final state and rewinding is faster.

4. A function has two parameters that should be independent. After running, you find that modifying one of them mysteriously changes the other. Which technique fits best?

• Add print statements to track every modification

  Print debugging is a fallback. The debugger has dedicated UI for spotting aliasing — use it.

• Set a conditional breakpoint on every line that touches either parameter

  Brute force, and you’ll discover the same answer the oid badge tells you in one glance.

• Inspect the oid badges in the Variables tab — if both names share the same oid, they’re the same object in memory
• Use back-in-time scrubbing

  Scrubbing tells you when state diverged. The oid badge tells you why (they’re the same object). For aliasing specifically, oid is the more direct cue.

5. You’ve spent 20 minutes setting and clearing breakpoints, making small edits, and rerunning tests. Nothing has worked, and you’re starting to feel frustrated. What’s the right next move?

• Push through — debugging always feels this way; just keep iterating

  Trying edit after edit without new evidence is a frustrating cycle that rarely ends productively. Stop and externalize: write down the symptom in plain words, list what hypotheses you’ve already ruled out and how, then re-pick a technique deliberately. The act of writing usually surfaces the next move.

• Restart the file from scratch with a fresh implementation

  A rewrite occasionally helps for tiny scripts, but it’s overkill here. The bug is hard because you don’t have a clear hypothesis yet — not because the code is structurally broken. Externalize the failure first.

• Stop. Write down — in plain words — the symptom (expected vs actual) and what hypotheses you’ve ruled out so far. Then re-pick a technique
• Ask a teammate to fix it for you

  Asking a teammate is a good follow-up move. Before that, externalize what you know. The act of writing the symptom and the ruled-out hypotheses often reveals the next move to you — and if it doesn’t, you now have a precise question rather than a vague one.

6. A test passes locally on your laptop but fails on the autograder. You’ve reproduced the failure on the autograder twice. What’s the most useful first move?

• Set a conditional breakpoint inside the function — clearly the issue is data-dependent

  A conditional breakpoint can’t help if you can’t reproduce the bug locally — the breakpoint never fires.

• Drag the History scrubber backward — clearly the symptom appears late

  Same problem — scrubbing requires running the program; if it doesn’t fail locally, you have nothing to scrub through.

• First, find a way to reproduce the failure locally. Without local reproduction, you can’t use any debugger technique productively
• Email the instructor for an autograder log

  An autograder log is useful, but the larger question is why environments differ. Sometimes the answer is OS, Python version, locale, or random seed. Reproducing locally is the necessary first step before any other technique becomes useful.

7. A test that previously passed now fails after a change you just made. The previous test still passes. What does this tell you?

• You introduced a regression. The bug is in the change you just made; revert and re-apply more carefully
• The test was wrong all along; update its expected value

  If the test previously passed and the only change is yours, the test isn’t suddenly wrong — the test caught a real regression. Updating the expected value is a workaround that hides the regression.

• You should add time.sleep(1) to make the test more deterministic

  Sleeps mask race conditions, but they don’t fix logic regressions. Adding sleeps to make tests pass is a known anti-pattern.

• You should ignore this — you’re focused on the previously-failing test

  Ignoring a regression because you’re focused elsewhere is exactly how regressions ship to production. Fix it now while the change is fresh in your head.

8. A payment processor handles 10,000 transactions. Two adjacent transactions produce totals that are slightly off — but only when a specific merchant ID appears. The failure is consistent run-to-run, and the wrong calculation fires exactly when the bad merchant ID is processed. Which technique fits best?

• Run to completion, then scrub the History scrubber backward — the symptom appears in the middle of the run

  Scrubbing works well when the symptom and cause are in different, temporally-separated moments — you need to rewind past several events that look fine. Here, the wrong calculation fires exactly when the bad merchant ID is processed: the symptom and cause are at the same moment. A conditional breakpoint that pauses only for that merchant ID is more direct.

• Set a conditional breakpoint with the predicate tx.merchant_id == SUSPECT_ID
• Inspect oid badges in the Variables tab — the totals might be aliased objects

  The symptom is a wrong value, not co-mutation of two names. Aliasing is the signature of two variables moving together unexpectedly — not of a single wrong calculation on one specific input.

• Step forward through all 10,000 transactions

  10,000 manual steps is precisely what conditional breakpoints are designed to avoid.

9. Which of these counts as evidence in the debugging cycle? (select all that apply)

• A specific value of a variable observed at a specific line, e.g., i = 1 at the start of the loop
• A failing test’s exact assertion message
• A vague hunch that ‘something feels off about the loop’

  A hunch is a seed for a hypothesis, not evidence. Evidence is observable, specific, and reproducible. Until the hunch is converted to a discriminating test or observation, it’s not yet evidence.

• A repr() of a string showing a hidden whitespace character

1. Which of the three earlier cases is this bug most structurally similar to?

• Case 1 (Maze Pathfinder, boundary bug in _dfs)

  Case 1 was a boundary / off-by-one bug — >= rejecting an exact-budget path. This bug isn’t about boundaries; it’s about input data having a hidden character (a \n) that broke equality with the expected key.

• Case 2 (Ledger Reconciliation, hidden-whitespace in CSV import)
• Case 3 (Course Waitlist, FIFO vs LIFO ordering)

  Case 3 was about order of admission (FIFO vs LIFO). This bug isn’t about ordering; the bug fires regardless of when the offending line is processed.

• None of them — this is a totally new bug family

  Surface looks different (file iteration vs CSV) but the family is identical: input data carries a stray whitespace character, normalization is missing at the loading layer, fix is strip() at the boundary. This is exactly Case 2.

2. (Final retrieval — spaced from Step 1.) Place these debugging-cycle stages in order: A. Verify B. Symptom C. Hypothesis D. Fix E. Evidence F. Localize G. Predict

• B → G → E → C → F → D → A
• B → D → A → C → E → F → G

  Fix and Verify before Hypothesis is the tinkering anti-cycle: edit, run, hope, repeat. The whole point of hypothesis-driven debugging is that the fix comes near the end of the process.

• G → B → C → E → F → D → A

  Predict before Symptom inverts the order. You can’t predict what should happen until you know what is happening. The Symptom is what triggers the cycle in the first place.

• B → E → G → C → F → D → A

  Predict before Evidence is closer to right but very close to wrong. Predict comes from understanding the spec; Evidence comes from running the program. The order is: Symptom (run) → Predict (what should the state be) → Evidence (collect actual state) → Hypothesis.

3. (Spaced retrieval — Step 1’s “no edit until stage 6” rule.) You’re 30 seconds into investigating a bug. You think you see the problem. What does the discipline say to do right now?

• Make the edit immediately while the insight is fresh

  Edit-first is the anti-pattern this tutorial is built to dismantle. Bugs that ‘felt obvious’ are exactly where confirmation bias lives — the discipline is to verbalize the hypothesis first.

• Form an explicit hypothesis (in words) before touching the code
• Run the failing test 3 more times to make sure it’s reproducible

  You should already have a reproducible failure (Step 1’s discipline) before you ever entered the investigation. Running the test more times is not the next move; committing to a hypothesis is.

• Consult the time-travel debugger first; insight without evidence is a hallucination

  TT-debugger is a tool for evidence-gathering, not a substitute for the hypothesis stage. Form the hypothesis first, then use the debugger to test it.

4. (Transfer — apply the cycle to a new case.) A teammate reports: “My function expand_aliases is supposed to look up names in aliases.json, but every key returns None.” Which stage of the debugging cycle did your teammate just do, and what’s the next stage?

• They gave a Symptom; the next stage is Predict
• They gave a Hypothesis; the next stage is Localize

  A hypothesis names a cause — e.g., ‘I think the JSON is failing to parse.’ Your teammate described what they observe (a symptom), not why it’s happening.

• They gave Evidence; the next stage is Verify

  Evidence is concrete observation (e.g., ‘I added print(repr(key)) and saw "name\n"’). ‘Every key returns None’ is a symptom — the externally visible fault — not the underlying evidence.

• They gave a Fix; the next stage is to confirm it works

  No fix has been proposed. They reported a problem; the cycle starts at Symptom and works forward.

5. (Spaced — Step 2’s aliasing badge.) Your code does:

def add_to(items: list[str] = []) -> list[str]:
    items.append("x")
    return items

print(add_to())   # ['x']
print(add_to())   # ['x', 'x']  ←  surprise

• Lists are immutable — calling .append actually creates a new list each time

  Lists are mutable (.append mutates in place). The bug here is real and the second call sees the first call’s mutation.

• Default arguments are evaluated once at function-definition time, so the same list is reused across calls
• Function calls inside a script always share their parameter memory unless copy.deepcopy is used

  Function parameter scoping is normal — local in scope, separate per call. The trap is only with mutable default values, because the default object is created once.

• Python caches small lists; [] always points to the same canonical empty list

  Python doesn’t intern empty lists. [] is [] returns False (try it). Default mutable args is a separate, well-documented Python footgun.