Context Managers: Solutions

# exercise_1.py
from typing import Self

class Trace:
    def __init__(self, name: str) -> None:
        self.name = name

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

    def __exit__(self, exc_type: type[BaseException] | None,
                 exc: object, tb: object) -> None:
        print(f"exit {self.name}")

with Trace("A") as t:
    print(f"inside {t.name}")
    with Trace("B") as u:
        print(f"inside {u.name}")
#: enter A
#: inside A
#: enter B
#: inside B
#: exit B
#: exit A

Entering is outside-in (A then B), and exiting is inside-out (B then A). B’s whole lifetime, enter and exit, sits nested inside A’s, the same last-in-first-out order Combining Context Managers shows for tag("ul") and tag("li") written on one with line. The order is the same whether you write the nesting as two separate with statements or as one comma-separated line.

# exercise_3.py
from collections.abc import Iterator
from contextlib import contextmanager

@contextmanager
def tag(name: str) -> Iterator[str]:
    print(f"<{name}>")
    try:
        yield name
    finally:
        print(f"</{name}>")

with (tag("ul") as outer, tag("li") as inner1,
      tag("li") as inner2):
    print(f"  {outer} then {inner1} then {inner2}")
#: <ul>
#: <li>
#: <li>
#:   ul then li then li
#: </li>
#: </li>
#: </ul>

All three managers enter left to right (ul, then li, then li again) and exit in reverse order, regardless of how many managers appear on the line. The pattern from two managers extends unchanged to three, four, or more.

# exercise_5.py
from collections.abc import Iterator
from contextlib import contextmanager

@contextmanager
def banner(title: str) -> Iterator[None]:
    print(f"=== {title} ===")
    try:
        yield
    finally:
        print(f"=== {title} ends ===")

@banner("outer")
@banner("inner")
def report() -> None:
    print("quarterly numbers")

report()
#: === outer ===
#: === inner ===
#: quarterly numbers
#: === inner ends ===
#: === outer ends ===

Apply the decorators bottom-up. The prediction is the same one stacking produces anywhere. Python reads the stack as report = banner("outer")(banner("inner")(report)). @banner("inner") is nearest the def, so it wraps report() first, and @banner("outer") then wraps the inner wrapper. Calling report() therefore enters the outer manager, which calls the inner wrapper, which enters the inner manager before running the body. Unwinding reverses that order, so the four bracketing lines nest rather than interleave.

Enter a fresh manager on each call. Each @banner(...) line builds one manager object, when Python defines report(). A generator manager is single-use, so the wrapper that ContextDecorator supplies does not enter that object. On each call of report() the wrapper builds a fresh manager from the same generator function and arguments, and enters that one. A hand-written class-based manager decorating a function re-enters the same instance on every call instead, so every call shares any state the instance holds.

If you return issubclass(exc_type, KeyError) without the None test, the demo prints the same two lines, because both of its blocks raise an exception. A block that finishes cleanly then fails: __exit__() receives None, and issubclass() raises a TypeError. ty reports an invalid-argument-type at the issubclass() call, so the type checker catches the mistake the demo misses. The solution tests exc_type is not None first.

# ignore_missing.py
from types import TracebackType
from exceptions import expected

class ignore_missing:
    def __enter__(self) -> None:
        return None

    def __exit__(
            self,
            exc_type: type[BaseException] | None,
            exc: BaseException | None,
            tb: TracebackType | None,
    ) -> bool:
        return (exc_type is not None
                and issubclass(exc_type, KeyError))

stock = {"apple": 3}

with ignore_missing():
    print(stock["pear"])
    print("never reached")
print("survived the KeyError")
#: survived the KeyError

with expected(ValueError):
    with ignore_missing():
        raise ValueError("not a lookup problem")
#: [ValueError] not a lookup problem

Suppress one exception type. __exit__() decides an exception’s fate through its return value: truthy suppresses, falsy lets the exception continue. Returning issubclass(exc_type, KeyError) therefore suppresses KeyError and propagates everything else. The second block confirms the propagation: the ValueError passes through ignore_missing and reaches the chapter’s expected, which prints it.

Handle a clean exit. The exc_type is not None test keeps the normal path working. When a block finishes without an exception, Python still calls __exit__(), passing None for all three arguments, and issubclass(None, KeyError) raises a TypeError. Checking for None first also lets the type checker narrow exc_type to type[BaseException], the type issubclass() requires.

The class uses a lowercase name because you use it like a function. contextlib.suppress is lowercase for the same reason.

Both calls to wrap() go, replaced by one call that reads the names from the command line:

import sys

wrap(sys.argv[1:])

Run with three names, uv run python exit_stack.py x y z:

open x
open y
open z
using ['x', 'y', 'z']
close z
close y
close x

Run with none, uv run python exit_stack.py:

using []

Close in reverse order of opening. enter_context() pushes each manager onto the stack as the comprehension walks the list left to right. Leaving the with unwinds that stack, so the closes come out in reverse. The reversal holds for any number of names, including zero, the property the exercise asks you to confirm.

The empty run is the more interesting one. Nothing opens, so nothing closes, and with ExitStack() as stack: still enters and exits correctly around a body whose stack stays empty. That degenerate case shows why ExitStack exists. A fixed with a, b, c: line settles its count in the source. ExitStack accepts a count settled only at runtime, zero included, and a command line is one source of such a count.

The sys.argv rewrite stays out of the extracted listings, because the book’s output checker runs every listing inside one process with its own arguments, and a script reading sys.argv sees the checker’s arguments instead. The listing below passes the names to wrap() directly, so the checker can run it, and it shows both cases:

# exercise_7.py
from collections.abc import Iterator
from contextlib import ExitStack, contextmanager

@contextmanager
def tag(name: str) -> Iterator[str]:
    print(f"open {name}")
    try:
        yield name
    finally:
        print(f"close {name}")

def wrap(names: list[str]) -> None:
    with ExitStack() as stack:
        open_tags = [stack.enter_context(tag(n))
                     for n in names]
        print("using", open_tags)

wrap([])
#: using []
wrap(["x", "y", "z"])
#: open x
#: open y
#: open z
#: using ['x', 'y', 'z']
#: close z
#: close y
#: close x

# exercise_8.py
from collections.abc import Iterator
from contextlib import contextmanager

@contextmanager
def careful(name: str) -> Iterator[str]:
    print(f"enter {name}")
    try:
        yield name
    finally:
        print(f"exit {name}")

try:
    with careful("A"):
        raise ValueError("boom")
except ValueError as error:
    print("caught:", error)
#: enter A
#: exit A
#: caught: boom

Clean up before the exception propagates. exit A now prints, and it prints before caught: boom. Python raises the block’s ValueError inside the generator, at the yield. The finally runs as the exception leaves the generator, and only then does the exception leave the with statement and reach the except. That is the order exit_on_error.py shows for the class form: cleanup first, then propagation.

In no_finally.py the same exception left the generator from the bare yield, so the print() after it did not run. The finally is the only difference between the two listings, apart from the function’s name.