Four things almost every Python interview opens with, because each one is quick to ask and quick to spot a gap in: closures, context managers, generators, and how Python decides which variable you mean when a name could refer to several.

Closures: a function that remembers where it came from

Picture a locker that comes pre-loaded with a note only that locker can read, even after the person who wrote the note has gone home. A closure is that: an inner function that keeps a live link to a variable from the function that created it, even after that outer function has already finished running.

make_multiplier(2) runs once, creates a little box (a "cell") holding 2, and hands back multiply with that box attached. Every later call to double(x) reads from that same box. It never re-reads anything from make_multiplier's call, which already ended. That's why double and triple behave differently even though they're built from the exact same code.

The classic trap: a closure captures the variable, not its value at the moment the closure was made.

All three lambdas in the broken version share one i box, and by the time any of them runs, the loop is over and i is stuck at 2. The fix works because default argument values are copied in at function-definition time, once per lambda, so i=i freezes that loop's current value instead of leaving it as a shared, still-changing variable.

Remember: a closure keeps a live link to a variable, not a snapshot of its value. A loop variable in a closure needs a default argument to freeze it.

Common mistake: building a list of callbacks inside a loop and expecting each one to remember "its" iteration's value without the i=i fix.

Context managers: guaranteed setup and cleanup

A context manager is an object that sets something up before your code runs and tears it down afterward, no matter what, even if your code raises an exception halfway through.

You can write your own two ways. Class-based, with __enter__/__exit__:

Or function-based, with @contextmanager, which is usually less code for a one-off:

Everything before yield plays the role of __enter__; everything after plays __exit__. Entering with timer(): runs timer() up to yield, then do_work() runs as the body, then execution resumes right after yield to print the elapsed time.

Common real uses: open() for files, threading.Lock() for acquiring and releasing a lock, a database connection for connect and disconnect, unittest.mock.patch for patching and restoring. Watch the __exit__ return value: True silently swallows any exception raised inside the block, which is rarely what you want.

Remember: everything before yield in a @contextmanager function is setup; everything after is cleanup, and cleanup still needs a try/finally around the yield if it must run even on error.

Generators: values produced one at a time

A generator is a function that hands out a lazy sequence of values with yield, instead of building and returning the whole list up front. Nothing runs until the caller actually asks for the next value.

Calling squares(5) doesn't run the function body at all, it just creates a generator object. The first next(gen) runs up to the first yield, producing 0, then pauses exactly there. The second next(gen) resumes right after that yield and continues the loop to i = 1. The payoff is memory, not raw speed: sum(x*x for x in range(10_000_000)) never holds ten million values at once, unlike the equivalent list comprehension.

Remember: a generator computes the next value only when asked. Use one whenever you'd otherwise build a huge list just to loop over it once.

LEGB: how Python finds a name

When your code uses a name, Python checks four scopes, in this order: Local (inside the current function), Enclosing (any function this one is nested inside), Global (the module level), Built-in (Python's own names like len). The first scope where the name exists wins.

Writing to an outer scope, rather than just reading it, needs an explicit declaration. This is the part people forget under pressure:

Without global count, Python sees the assignment count += 1 anywhere in the function body and decides, before the function even runs, that count is a local variable for the whole function. That makes the read half of count += 1 fail, since the local count was never assigned before that line runs. nonlocal does the same job one level up: it lets a nested function write to its enclosing function's variable, not the global one.

Remember: Python looks up a name Local, then Enclosing, then Global, then Built-in. Writing to an outer scope needs global or nonlocal; reading it does not.

The mutable default argument trap

Default argument values are evaluated once, when the def line runs, not once per call. So [] here is a single list object, shared and mutated by every call that doesn't pass its own cart.

None is a safe, immutable default. Inside the function, a brand-new list is created on every call that didn't supply its own, so callers stop unknowingly sharing state.

Remember: a mutable default argument is created once at definition time and shared across every call. Use None as the default and build the real value inside the function.