What is a closure, and what's the late-binding pitfall with closures in loops?

A closure is a nested function that **remembers variables from its enclosing scope** even after that scope has finished executing, by keeping a reference to the enclosing variable (a "cell"), not a snapshot of its value at creation time. The classic pitfall: closures created in a loop (e.g., a list of lambdas) all share the **same** loop variable, so by the time they're called, they all see its *final* value — not the value at the time each closure was created.

How do decorators work, and how do you write one that accepts arguments?

A decorator is a function that takes a function and returns a (usually wrapped) function; `@decorator` above a `def` is syntax sugar for `func = decorator(func)`. A **decorator that takes arguments** needs an extra level of nesting: the outer function takes the arguments and returns the actual decorator, which takes `func` and returns the wrapper.

What does `functools.wraps` do, and why is it important?

Without it, a decorator's wrapper function **replaces** the original function's `__name__`, `__doc__`, and other metadata with the wrapper's own — so `help(func)`, `func.__name__`, and introspection tools see the wrapper, not the original. `@functools.wraps(func)` copies that metadata onto the wrapper, preserving the illusion that the decorated function is still "itself" for debugging, documentation, and tools that rely on `__name__`/`__wrapped__`.

What does `functools.lru_cache` do, and when should you use it?

`@functools.lru_cache(maxsize=...)` memoizes a function's return value keyed by its arguments, so repeated calls with the same (hashable) arguments return the cached result instantly instead of recomputing. It's ideal for pure, deterministic functions with expensive computation and a bounded set of distinct inputs — e.g., recursive algorithms (Fibonacci), or repeated lookups — but the arguments must be hashable, and it can leak memory if used carelessly on methods holding a reference to `self`.

What is `functools.partial`, and how does it differ from a lambda?

`functools.partial(func, *args, **kwargs)` creates a new callable with some arguments **pre-filled**, returning a real, introspectable object (with `.func`, `.args`, `.keywords` attributes) rather than a throwaway closure. It's functionally similar to a lambda that forwards extra arguments, but is more explicit, slightly faster, picklable (lambdas aren't), and self-documenting about which arguments are fixed.

What are lambda functions, and when should you avoid them?

A `lambda` is an anonymous, single-expression function — `lambda x: x * 2` is equivalent to a `def` with one `return` statement, but has no name, no statements (only one expression), and no docstring. Use lambdas for short, throwaway callbacks (`sorted(key=lambda x: x.name)`); avoid them for anything that needs a name for debugging/tracebacks, has multiple logical steps, or would benefit from a docstring — PEP 8 explicitly recommends `def` over binding a lambda to a name.

What's the difference between a positional-only, keyword-only, and regular parameter?

A regular parameter can be passed either positionally or by keyword. Parameters after a bare `*` in the signature are **keyword-only** — they must be passed by name. Parameters before a bare `/` (Python 3.8+) are **positional-only** — they cannot be passed by name. These markers let API authors control call-site flexibility: positional-only protects against callers depending on a parameter name that might change; keyword-only forces clarity for ambiguous or rarely-used options.

How do you write a decorator that preserves a function's signature for tools like IDEs and type checkers?

Using `*args, **kwargs` in the wrapper (the usual decorator pattern) hides the wrapped function's real parameter names and types from IDEs, type checkers, and `inspect.signature()` unless you also apply `functools.wraps`, which copies `__wrapped__` — and `inspect.signature()` specifically follows `__wrapped__` to recover the original signature. For strict static typing, use `ParamSpec` (PEP 612) so `mypy` can verify the wrapper's `*args, **kwargs` match the original function's actual parameter types.

Functions, Closures & Decorators

First-class functions, closures and late binding, decorator mechanics, and functools utilities.

Difficulty

Open as page

What makes something a closure

def make_multiplier(factor):
    def multiply(x):
        return x * factor       # `factor` is captured from the enclosing scope
    return multiply

double = make_multiplier(2)
triple = make_multiplier(3)
double(5)   # 10
triple(5)   # 15

multiply is a closure over factor — even after make_multiplier returns, multiply still has access to its own factor, because Python keeps the enclosing variable alive as long as any closure references it. double and triple each capture a different factor because each call to make_multiplier creates a fresh scope.

The late-binding trap

funcs = []
for i in range(3):
    funcs.append(lambda: i)

[f() for f in funcs]   # [2, 2, 2]  -- NOT [0, 1, 2]!

Every lambda captures the variable i by reference, not its value at the time the lambda was created. Since all three lambdas share the same enclosing scope (the loop body doesn't create a new scope per iteration — loops don't introduce scopes in Python at all), by the time they're called, i has already finished the loop and holds its final value, 2.

The fix: bind the value via a default argument

funcs = []
for i in range(3):
    funcs.append(lambda i=i: i)   # default arg is evaluated NOW, at def-time

[f() for f in funcs]   # [0, 1, 2]

Default argument values are evaluated once, when the lambda/def is created — using i=i copies the current value of i into the function's own default, decoupling it from the loop variable's later mutations.

Alternative fix: a factory function

def make_getter(value):
    return lambda: value    # closes over `value`, a fresh parameter per call

funcs = [make_getter(i) for i in range(3)]
[f() for f in funcs]   # [0, 1, 2]

Each call to make_getter creates a genuinely new scope with its own value, so each returned lambda captures a distinct variable — this is the same principle as make_multiplier above, just applied to fix the loop pitfall.

Interview-ready summary: Closures capture variables by reference to the enclosing scope, not by value — which is powerful for building factories/decorators but means closures created in a loop all share the loop variable and see its final value unless you force early binding (default argument trick or a separate factory function per iteration).

Related Resources

Nested scopes — Python docs

Open as page

What `@decorator` actually does

def shout(func):
    def wrapper(*args, **kwargs):
        result = func(*args, **kwargs)
        return result.upper()
    return wrapper

@shout
def greet(name):
    return f"hello, {name}"

# equivalent to:
# def greet(name): ...
# greet = shout(greet)

greet("ada")   # 'HELLO, ADA'

@shout just rebinds the name greet to whatever shout(greet) returns — here, the wrapper closure, which calls the original greet and transforms its result. func is captured in wrapper's closure, so it's still callable even though greet itself has been reassigned.

A decorator that takes its own arguments

def repeat(times):
    def decorator(func):
        def wrapper(*args, **kwargs):
            results = []
            for _ in range(times):
                results.append(func(*args, **kwargs))
            return results
        return wrapper
    return decorator

@repeat(times=3)
def roll_die():
    import random
    return random.randint(1, 6)

# equivalent to:
# roll_die = repeat(times=3)(roll_die)

roll_die()   # [4, 1, 6]  (three rolls)

Three levels: repeat(times) returns decorator; decorator(func) returns wrapper; calling wrapper(...) finally runs the original function. @repeat(times=3) evaluates repeat(times=3) first (producing decorator), then applies that to roll_die — this is why a parameterized decorator always needs parentheses even with no arguments inside them (@repeat()), while a plain decorator never does (@shout, not @shout()).

Stacking multiple decorators

@decorator_a
@decorator_b
def f(): ...

# equivalent to: f = decorator_a(decorator_b(f))

Decorators apply bottom-up: the one closest to the function runs first (wraps first), so the outermost decorator in the source is the outermost wrapper at call time.

Class-based decorators

class CountCalls:
    def __init__(self, func):
        self.func = func
        self.calls = 0

    def __call__(self, *args, **kwargs):
        self.calls += 1
        return self.func(*args, **kwargs)

@CountCalls
def greet():
    return "hi"

greet(); greet()
greet.calls   # 2

Any object with __call__ can be a decorator — a class-based decorator is useful when the wrapper needs to hold non-trivial state (here, a call counter) rather than a single closed-over variable.

Interview-ready summary: @decorator is sugar for func = decorator(func); a decorator that itself takes arguments needs an extra function layer (args -> decorator -> wrapper). Decorators stack bottom-up, and anything callable — including a class implementing __call__ — can serve as one.

Related Resources

Decorators — Python docs (glossary)

Open as page

The problem without `wraps`

def logged(func):
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

@logged
def add(a, b):
    """Add two numbers."""
    return a + b

add.__name__    # 'wrapper'  -- lost the real name!
add.__doc__     # None       -- lost the docstring!
help(add)        # shows wrapper's (empty) signature/doc, not add's

Every function decorated with logged reports its name as "wrapper" and loses its docstring — this breaks help(), auto-generated API docs, debuggers, and any code that inspects func.__name__ (e.g., logging frameworks that print the function name).

The fix

import functools

def logged(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

@logged
def add(a, b):
    """Add two numbers."""
    return a + b

add.__name__    # 'add'
add.__doc__     # 'Add two numbers.'
add.__wrapped__ # <function add at ...> -- the original, un-decorated function

functools.wraps(func) is itself a decorator (built on functools.update_wrapper) that copies __name__, __doc__, __module__, __qualname__, and __dict__ from func onto wrapper, and sets wrapper.__wrapped__ = func so introspection tools can find the original if needed.

Why this matters beyond cosmetics

Debugging/tracebacks: stack traces show the wrapper's name unless metadata is copied, making it harder to tell which decorated function actually failed.
Documentation tools (Sphinx, help()) rely on __doc__/__name__ to generate correct docs — without wraps, every decorated function's docs would show up as generic wrapper boilerplate.
Other decorators/frameworks that inspect __name__ (e.g., some testing or routing frameworks match handlers by function name) would silently break.

Interview-ready summary: A decorator's inner wrapper function shadows the original function's identity (__name__, __doc__, etc.) unless you explicitly restore it with @functools.wraps(func) — treat it as mandatory boilerplate any time you write a decorator, not an optional nicety.

Related Resources

functools.wraps — Python docs

Open as page

Basic usage: memoizing an expensive pure function

import functools

@functools.lru_cache(maxsize=128)
def fib(n):
    if n < 2:
        return n
    return fib(n - 1) + fib(n - 2)

fib(35)   # fast -- each unique n is computed once, then cached
fib.cache_info()   # CacheInfo(hits=32, misses=36, maxsize=128, currsize=36)

Without caching, naive recursive fib is exponential (recomputes the same sub-calls repeatedly). lru_cache turns it into linear time by remembering every fib(n) result already computed — an "LRU" (least recently used) eviction policy discards the oldest entries once maxsize is exceeded (or never evicts, if maxsize=None).

Requirements and gotchas

Arguments must be hashable — you can't cache a call with a list or dict argument, since the cache key is built from the arguments themselves (as if put in a dict). Pass tuples or frozensets instead.
Only for pure functions — the cache doesn't know if the function has side effects or depends on external mutable state; caching a function whose result depends on something other than its arguments (current time, a database row that can change) will return stale results.
Memory: maxsize=None caches unboundedly — fine for a small, fixed input domain, dangerous for functions called with unbounded/unique arguments (e.g., caching by user-supplied string with no upper bound).
Caching instance methods: @lru_cache on a method caches by (self, *args), which keeps self alive for as long as the cache entry exists — this can prevent garbage collection of instances you expected to be freed. A common workaround is caching a module-level function that takes only the needed hashable data instead of the whole self.

`cache` vs `lru_cache`

@functools.cache   # Python 3.9+, equivalent to lru_cache(maxsize=None)
def expensive(n):
    ...

functools.cache is a simpler alias for an unbounded cache, useful when you know the input domain is naturally small/finite and don't need eviction.

Interview-ready summary: lru_cache memoizes pure functions keyed by their (hashable) arguments, turning repeated/recursive expensive computation into cheap lookups — but it requires hashable arguments, assumes no side effects or external state dependence, and can extend an object's lifetime unexpectedly when applied to instance methods.

Related Resources

functools.lru_cache — Python docs

Open as page

Basic usage

from functools import partial

def power(base, exponent):
    return base ** exponent

square = partial(power, exponent=2)
cube = partial(power, exponent=3)

square(5)   # 25
cube(5)     # 125

square and cube are new callables with exponent pre-bound; calling them only needs the remaining argument (base).

Equivalent lambda

square = lambda base: power(base, exponent=2)

Functionally similar for simple cases, but partial has real advantages:

Introspectable: square.func, square.args, square.keywords let you inspect what's pre-filled — useful for debugging or building generic tooling around partially-applied callables.
Picklable: partial objects can be pickled (as long as the underlying function and bound arguments are), which matters for multiprocessing (worker functions passed to a process pool must be picklable) — a lambda cannot be pickled at all.
Clearer intent: partial(power, exponent=2) reads as "power, with exponent fixed at 2," which is more self-documenting than a lambda wrapping a call.

A common real use: `multiprocessing`/callback APIs

from functools import partial
from multiprocessing import Pool

def process(item, config):
    return item * config["factor"]

with Pool() as pool:
    results = pool.map(partial(process, config={"factor": 3}), [1, 2, 3])

Since worker functions passed across process boundaries must be picklable, partial is the standard way to "bake in" extra arguments for a function used as a callback, where a lambda would fail to pickle.

Interview-ready summary: partial pre-fills some of a function's arguments and returns a new, real callable object — functionally similar to a wrapping lambda, but introspectable and picklable, which matters for tooling and multiprocessing in particular.

Related Resources

functools.partial — Python docs

Open as page

What a lambda is

square = lambda x: x * x
# equivalent to:
def square(x):
    return x * x

A lambda is restricted to a single expression — no statements (no if/for blocks, no multiple lines, no assignments other than the walrus operator inside the expression). Its return value is always that one expression's result.

Good uses: short, inline, throwaway callbacks

people.sort(key=lambda p: p.last_name)
sorted(words, key=lambda w: (-len(w), w))
list(filter(lambda x: x % 2 == 0, numbers))
button.on_click(lambda: print("clicked"))

These are idiomatic — the lambda exists only to describe "how to sort/ filter this," used once, right where it's needed, and naming it separately would add indirection without adding clarity.

Why PEP 8 discourages binding a lambda to a name

# PEP 8: don't do this
f = lambda x: x * 2

# do this instead
def f(x):
    return x * 2

Once you're naming the function anyway, def is strictly better:

Tracebacks show the real name. A named lambda's __name__ is literally "<lambda>", which makes stack traces harder to read.
def supports a docstring, statements, multiple lines, and default values with the same clarity as any other function.
No expressiveness advantage — a bound lambda can't do anything a one-line def can't, so there's no upside to the restriction.

Lambdas can't contain statements — a common trip-up

lambda x: print(x); return x   # SyntaxError -- can't have multiple statements
lambda x: x if x > 0 else -x   # OK -- this is a conditional EXPRESSION, not a statement

A conditional expression (a if cond else b) is fine inside a lambda; actual statements (if, for, try, assignment, return) are not.

Interview-ready summary: Lambdas are single-expression anonymous functions, ideal for short inline callbacks like sort keys or simple filters. The moment a lambda is complex enough to need a name, multiple steps, or a docstring, write a regular def instead — PEP 8 treats name = lambda: ... as an anti-pattern.

Related Resources

Lambda expressions — Python docs

Open as page

The three parameter kinds

def f(pos_only, /, regular, *, kw_only):
    ...

f(1, 2, kw_only=3)          # OK
f(1, regular=2, kw_only=3)  # OK -- `regular` can be positional or keyword
f(pos_only=1, regular=2, kw_only=3)   # TypeError -- pos_only can't be a keyword
f(1, 2, 3)                             # TypeError -- kw_only must be named

Everything before / is positional-only: callers cannot use the parameter name at the call site at all.
Everything after * is keyword-only: callers must use the parameter name; passing it positionally is an error.
Everything between / and * (or with no markers used) is regular — callable either way.

Why keyword-only matters: clarity for ambiguous calls

def create_user(name, *, is_admin=False, send_email=True):
    ...

create_user("ada", True, False)          # not allowed -- what do True/False mean?!
create_user("ada", is_admin=True, send_email=False)   # forced to be explicit

Forcing is_admin/send_email to be keyword-only prevents a call site like create_user("ada", True, False), where a reader has no idea which boolean means what without checking the signature.

Why positional-only matters: API stability

def len(obj, /):
    ...

Many built-ins (len, abs, pow) are positional-only in their actual C implementation, and Python surfaces that with /. Marking a parameter positional-only means you can later rename it in a new library version without breaking any caller — since no caller was allowed to depend on the name in the first place. This matters most for public library APIs where the parameter name isn't a meaningful part of the contract but the position is.

Combining both

def divide(a, b, /, *, rounding=None):
    ...

divide(10, 3)                 # OK
divide(10, 3, rounding="up")  # OK
divide(a=10, b=3)               # TypeError -- a, b are positional-only

Interview-ready summary: / marks everything before it as positional-only (protects the parameter name from becoming part of the public contract); * marks everything after it as keyword-only (forces callers to be explicit). Regular parameters, with neither marker, accept both call styles — the default and most common case.

Related Resources

Function definitions — Python docs

Open as page

The problem: `*args, **kwargs` erases the real signature

def logged(func):
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

@logged
def add(a: int, b: int) -> int:
    return a + b

import inspect
inspect.signature(add)   # (*args, **kwargs) -- the real signature is gone!

An IDE's autocomplete, a type checker, and inspect.signature() all see wrapper's generic (*args, **kwargs) instead of add's real (a: int, b: int) -> int — you lose parameter hints and static type checking on every call to add.

Fix 1: `functools.wraps` restores runtime introspection

import functools

def logged(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        return func(*args, **kwargs)
    return wrapper

@logged
def add(a: int, b: int) -> int:
    return a + b

inspect.signature(add)   # (a: int, b: int) -> int -- recovered!

functools.wraps sets wrapper.__wrapped__ = func, and inspect.signature() specifically follows __wrapped__ to find the original signature — this fixes help(), IDE tooltips that use inspect, and documentation generators.

Fix 2: `ParamSpec` for static type-checker correctness

functools.wraps fixes runtime introspection, but mypy still needs generic type annotations on the decorator itself to verify that calls to the decorated function are type-correct:

from typing import Callable, TypeVar
from typing_extensions import ParamSpec
import functools

P = ParamSpec("P")
R = TypeVar("R")

def logged(func: Callable[P, R]) -> Callable[P, R]:
    @functools.wraps(func)
    def wrapper(*args: P.args, **kwargs: P.kwargs) -> R:
        return func(*args, **kwargs)
    return wrapper

@logged
def add(a: int, b: int) -> int:
    return a + b

add("x", "y")   # mypy error: expects int, got str

ParamSpec (PEP 612, Python 3.10+, or via typing_extensions earlier) lets the decorator's type signature say "whatever parameters func accepts, wrapper accepts the same ones" — without it, mypy would only know wrapper takes (*args: Any, **kwargs: Any) and couldn't catch a call-site type mismatch like passing strings to add.

Interview-ready summary: A naive *args, **kwargs decorator hides the wrapped function's signature from both runtime introspection and static type checkers. functools.wraps fixes the runtime side via __wrapped__; ParamSpec fixes the static-typing side by letting mypy propagate the original function's actual parameter types through the decorator.

Related Resources

typing.ParamSpec — Python docs

Functions, Closures & Decorators

What is a closure, and what's the late-binding pitfall with closures in loops?

What makes something a closure

The late-binding trap

The fix: bind the value via a default argument

Alternative fix: a factory function

Related Resources

How do decorators work, and how do you write one that accepts arguments?

What @decorator actually does

A decorator that takes its own arguments

Stacking multiple decorators

Class-based decorators

Related Resources

What does `functools.wraps` do, and why is it important?

The problem without wraps

The fix

Why this matters beyond cosmetics

Related Resources

What does `functools.lru_cache` do, and when should you use it?

Basic usage: memoizing an expensive pure function

Requirements and gotchas

cache vs lru_cache

Related Resources

What is `functools.partial`, and how does it differ from a lambda?

Basic usage

Equivalent lambda

A common real use: multiprocessing/callback APIs

Related Resources

What are lambda functions, and when should you avoid them?

What a lambda is

Good uses: short, inline, throwaway callbacks

Why PEP 8 discourages binding a lambda to a name

Lambdas can't contain statements — a common trip-up

Related Resources

What's the difference between a positional-only, keyword-only, and regular parameter?

The three parameter kinds

Why keyword-only matters: clarity for ambiguous calls

Why positional-only matters: API stability

Combining both

Related Resources

How do you write a decorator that preserves a function's signature for tools like IDEs and type checkers?

The problem: *args, **kwargs erases the real signature

Fix 1: functools.wraps restores runtime introspection

Fix 2: ParamSpec for static type-checker correctness

Related Resources

What `@decorator` actually does

The problem without `wraps`

`cache` vs `lru_cache`

A common real use: `multiprocessing`/callback APIs

The problem: `*args, **kwargs` erases the real signature

Fix 1: `functools.wraps` restores runtime introspection

Fix 2: `ParamSpec` for static type-checker correctness