Python Nested Context Managers: Syntax and Exit Order

When a single operation needs multiple resources — a file handle, a lock, a database connection — the order in which those resources are acquired and released determines whether the code is correct. Python's with statement handles this through context managers, and python nested context managers is the pattern you use when one resource depends on another or when several resources must be cleaned up together.

The with statement guarantees that __exit__ is called even when the body raises an exception. Nesting with statements extends that guarantee to multiple resources, but the ordering rules matter.

Nesting with Statements Directly

The most explicit way to nest context managers is to place one with statement inside another:

with open("input.txt", "r") as source:
    with open("output.txt", "w") as target:
        data = source.read()
        target.write(data.upper())

Each with statement enters its context manager when execution reaches it and exits when its block completes. The inner block runs entirely within the outer context, so the outer resource remains available for the entire duration of the inner block. If target.write raises an exception, both files are closed: the inner with closes target, and the outer with closes source.

This form is verbose but explicit. Each level of nesting is visually obvious, which helps when the resources have different lifetimes or when one resource is conditionally acquired.

Combining Context Managers in One with Statement

Python 2.7 and 3.1 added the ability to combine multiple context managers in a single with statement:

with open("input.txt", "r") as source, open("output.txt", "w") as target:
    data = source.read()
    target.write(data.upper())

This is semantically equivalent to the nested form. The context managers are entered from left to right, and the combined block runs after all of them have been entered. When the block exits, the context managers are closed in reverse order.

The combined form reads more cleanly when the resources are independent and have the same lifetime. It also avoids deep indentation when several resources are needed. However, it becomes hard to read when there are more than three or four context managers, because the with line grows long and the relationship between the resources is not visually obvious.

Exit Order: Last In, First Out

The critical behavior to understand is the exit order. Context managers exit in reverse order of entry — the last one entered is the first one exited. This is LIFO (last in, first out) order.

class Tracer:
    def __init__(self, name):
        self.name = name

    def __enter__(self):
        print(f"enter {self.name}")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        print(f"exit {self.name}")
        return False

with Tracer("outer"), Tracer("inner"):
    print("body")

The output is:

enter outer
enter inner
body
exit inner
exit outer

This LIFO order is deliberate. It mirrors how resources are typically acquired and released: you acquire the outer resource first, then the inner one, and you release the inner one before the outer one. For example, you open a file, then acquire a lock on it, and you must release the lock before closing the file. If the exit order were FIFO, the file would be closed while the lock was still held, which could allow another thread to read a partially written file.

Exception Propagation Through Nested Context Managers

When an exception occurs in the body of a nested with statement, the exception propagates outward. Each context manager's __exit__ method is called in turn, starting with the innermost one. If any __exit__ method returns True, the exception is suppressed at that level and does not propagate further outward.

class Suppressor:
    def __init__(self, name):
        self.name = name

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if exc_type is ValueError:
            print(f"{self.name} suppressed ValueError")
            return True
        return False

with Suppressor("outer"), Suppressor("inner"):
    raise ValueError("boom")

The inner Suppressor sees the ValueError first and returns True, so the exception is suppressed before it reaches the outer context manager. The outer __exit__ is still called, but with exc_type set to None, because the exception never propagated to it.

This behavior matters when you rely on an outer context manager to handle errors. If an inner context manager suppresses the exception, the outer one never sees it. Conversely, if the inner __exit__ returns False, the exception continues outward and the outer __exit__ receives it.

Using ExitStack for Dynamic Resource Sets

The contextlib.ExitStack class provides a more flexible way to manage nested context managers, especially when the number of resources is not known until runtime:

from contextlib import ExitStack

def process_files(filenames):
    with ExitStack() as stack:
        files = [stack.enter_context(open(name, "r")) for name in filenames]
        for f in files:
            print(f.read())

ExitStack tracks every context manager entered and closes them all in reverse order when the with block exits. This is useful when you need to open a variable number of files, acquire several locks conditionally, or register cleanup callbacks that must run in a specific order.

ExitStack also supports callback and pop_all methods. callback registers a function to run on exit, and pop_all transfers all registered context managers and callbacks to a new ExitStack, which is useful when you want to defer cleanup to a later point.

Performance and Maintainability Considerations

Nesting context managers has negligible runtime overhead — the __enter__ and __exit__ calls are ordinary method invocations. The real cost is in the resources themselves: each context manager may acquire a lock, open a file, or start a database transaction, and those operations have real costs.

The main maintainability concern is the order of exit. If you nest context managers in the wrong order, you can release a resource before its dependent resource is done. For example, closing a database connection before committing a transaction, or releasing a lock while still holding a file handle.

The single-statement form is compact but can obscure the dependency between resources. The nested form makes the dependency explicit but adds indentation. ExitStack is the right choice when the number of resources is dynamic or when you need to conditionally enter a context manager.

A practical rule: use the single-statement form for two or three independent resources with the same lifetime, use the nested form when one resource logically contains another, and use ExitStack when the resource set is dynamic.

Common Mistakes and Edge Cases

One common mistake is assuming that the as target of the outer context manager is not available inside the inner block. It is — the outer __enter__ runs before the inner block starts, so the target is bound and accessible.

Another edge case: if the inner with statement raises an exception during its own __enter__ call, the outer context manager's __exit__ is still called. The outer resource is released properly even though the inner resource was never acquired.

class FailingEnter:
    def __enter__(self):
        raise RuntimeError("cannot enter")

    def __exit__(self, exc_type, exc_val, exc_tb):
        print("inner exit called")
        return False

with Tracer("outer"):
    with FailingEnter():
        pass

The outer Tracer context manager still exits cleanly, and its __exit__ receives the RuntimeError raised by the failed inner __enter__. The inner __exit__ is not called because the inner context manager never entered successfully.

A third edge case involves the return value of __exit__. If an inner context manager returns True, it suppresses the exception, and the outer context manager's __exit__ is called with exc_type set to None. Code in the outer __exit__ that assumes an exception is always present will fail. Always check exc_type before using the exception value.