Closures and Scope — The LEGB Rule

# L — Local:     names assigned inside the current function
# E — Enclosing:  names in any enclosing function (for nested functions)
# G — Global:     names assigned at the top level of the module
# B — Built-in:   names Python provides automatically (len, print, str, ...)

x = "global x"

def outer():
    x = "enclosing x"

    def inner():
        x = "local x"
        print(x)          # "local x" — found immediately in Local scope, search stops there

    inner()
    print(x)               # "enclosing x" — Local scope for outer() has its own x

print(x)                    # "global x"

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

double = make_multiplier(2)
triple = make_multiplier(3)

print(double(5))    # 10 — remembers factor=2, even though make_multiplier already returned
print(triple(5))    # 15 — a COMPLETELY separate captured factor=3

print(double.__closure__[0].cell_contents)   # 2
print(triple.__closure__[0].cell_contents)   # 3

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

print([f() for f in functions])
# [2, 2, 2]  <- probably not what you expected!
# All three lambdas share the SAME "i" variable, which is 2 by the time
# any of them are actually called, since the loop has already finished

functions = []
for i in range(3):
    functions.append(lambda i=i: i)   # i=i: default arguments are evaluated immediately, at DEFINITION time

print([f() for f in functions])
# [0, 1, 2]  <- correct now

def make_counter():
    count = 0

    def increment():
        count = count + 1   # UnboundLocalError!
        return count

    return increment

counter = make_counter()
counter()
# UnboundLocalError: cannot access local variable 'count' where it is not associated with a value

def make_counter():
    count = 0

    def increment():
        nonlocal count       # "count" here refers to the enclosing scope's variable
        count = count + 1
        return count

    return increment

counter = make_counter()
print(counter())   # 1
print(counter())   # 2 — the enclosing "count" genuinely persists and increments across calls

counter = 0

def increment():
    global counter
    counter += 1

increment()
increment()
print(counter)   # 2

An engineer builds a control panel that dynamically creates one callback function per actuator, in a loop, each meant to send that actuator's specific ID when triggered. Every single button ends up controlling the last actuator in the list, no matter which one is actually pressed.

callbacks = {}
for actuator_id in actuator_ids:      # e.g. [101, 102, 103]
    callbacks[actuator_id] = lambda: send_command(actuator_id)

# Later, when any button is pressed:
callbacks[101]()   # sends command for 103! Every callback shares the SAME actuator_id variable

callbacks = {}
for actuator_id in actuator_ids:
    callbacks[actuator_id] = lambda aid=actuator_id: send_command(aid)

callbacks[101]()   # correctly sends command for 101 now

Why this specific bug is so common in real production code

It shows up constantly in any code that builds a batch of similar callbacks in a loop — UI event handlers, per-item processing functions queued for later execution, or handler dictionaries exactly like this one. The bug is especially dangerous because it produces no error at all — the code runs, every button appears to work, and it is only the specific behaviour (always controlling the wrong actuator) that reveals something is wrong, often much later than the line that actually caused it.