Closures

Understanding Lexical Scoping

To understand closures, one must first grasp lexical scoping in Python. Lexical scoping means that the accessibility of variables is determined by their physical location within the source code during definition. When a function is defined, it creates a scope that can access its own local variables, but also the variables defined in its parent scope. This relationship is static; it does not change regardless of where or when the function is eventually called. When an inner function references a variable from an outer function, that variable becomes part of the inner function's 'closure'. Even after the outer function finishes executing and its own local scope is destroyed, the inner function retains a reference to those specific variables in a special attribute called __closure__. This effectively allows the inner function to 'carry' its environment with it, maintaining access to the outer variables as if they were still in scope during every invocation.

# The inner function 'greet' has access to 'prefix' defined in 'make_greeter'
def make_greeter(prefix):
    def greet(name):
        # 'prefix' is accessed from the enclosing scope
        return f"{prefix}, {name}!"
    return greet

# 'morning_greeter' is a closure holding 'prefix' as 'Good morning'
morning_greeter = make_greeter("Good morning")
print(morning_greeter("Alice"))

Capturing State via Non-local Variables

Closures go beyond simple read-only access; they allow for stateful operations by capturing variables. If an inner function needs to modify a variable defined in the outer scope, we must use the 'nonlocal' keyword. Without this keyword, attempting to assign a value to a variable from an outer scope would simply create a new local variable within the inner function, shadowing the outer one. By explicitly declaring a variable as 'nonlocal', you instruct the interpreter to look for that variable in the nearest enclosing scope and bind it for modification. This creates a powerful pattern where the inner function acts as a persistent state manager. Each time the closure is invoked, it updates the captured state, and those changes persist for the next call. This mechanism is essentially a lightweight alternative to creating an entire class just to maintain a single counter or a specific configuration state, making your code significantly more concise.

# A counter closure using 'nonlocal' to update captured state
def create_counter():
    count = 0  # This variable is captured
    def increment():
        nonlocal count  # Required to modify the outer variable
        count += 1
        return count
    return increment

counter = create_counter()
print(counter()) # Returns 1
print(counter()) # Returns 2

Encapsulating Logic with Closures

Encapsulation is the practice of hiding internal state and requiring all interaction to occur through a public interface. Closures facilitate this perfectly because the captured environment variables are entirely inaccessible from outside the function. They cannot be modified or inspected directly by any external code, providing a clear boundary for your logic. This 'private' data remains safely isolated within the function's scope, ensuring that the integrity of the state is maintained throughout the object's lifecycle. By returning only the inner function, you expose a clean interface to the user, while the internal complexity and state tracking remain hidden. This approach is highly effective for building modular components, such as API wrappers or data processing pipelines, where specific configuration parameters need to be 'baked in' at creation time without cluttering the global namespace or requiring the overhead of complex class definitions or inheritance hierarchies.

# Encapsulating a power-raising function
def power_factory(exponent):
    # 'exponent' is encapsulated and hidden from the outside
    def raise_to(base):
        return base ** exponent
    return raise_to

square = power_factory(2)
cube = power_factory(3)
print(square(4)) # 16
print(cube(4))   # 64

The Trap of Late Binding

A common mistake when working with closures involves 'late binding'. This occurs when a closure captures a variable by reference rather than by value, often inside a loop. If multiple closures are created in a loop and all refer to the same loop variable, they will all see the final value assigned to that variable when they are executed. This is because the variable is captured by its name in the outer scope, not by its snapshot value at the moment the closure is defined. To fix this, you must force the binding of the current variable value by using default arguments. By passing the loop variable as a default argument, the closure captures the value at the time of definition, creating a local copy within the inner function signature. Understanding this distinction between reference and value binding is critical for avoiding subtle, hard-to-track bugs when generating functions dynamically through iterations.

# Late binding trap: all functions will print 2
funcs = [lambda: i for i in range(3)]
print([f() for f in funcs]) # [2, 2, 2]

# The fix: capture by default argument
fixed_funcs = [lambda x=i: x for i in range(3)]
print([f() for f in fixed_funcs]) # [0, 1, 2]

Closures vs Classes

Choosing between a closure and a class depends largely on the complexity of your requirements. Closures are ideal for simple, single-method objects that require only a small amount of state to function. They are lightweight, memory-efficient, and easy to define on the fly, which makes them perfect for functional programming styles and decorators. However, if your object needs to expose multiple methods that modify the same state, or if the internal state management becomes complex, a class is the superior choice. Classes provide a more structured approach with explicit state definition, better debugging support, and inheritance capabilities. A class-based structure makes the relationship between data and behavior transparent, which is essential for large, maintainable systems. Use closures for localized behavior and quick state capture, but pivot to classes when your logic grows to include multiple behaviors and extensive object interaction.

# A class compared to a closure
class Counter:
    def __init__(self): self.count = 0
    def __call__(self): self.count += 1; return self.count

# Closures are usually shorter for single-function tasks
counter_obj = Counter()
print(counter_obj()) # 1

Interview questions

All Python interview questions →

Check yourself

Take the full Python quiz →