Context Managers and the with Statement

f = open("data.txt")
data = f.read()
process(data)     # if this raises an exception, f.close() below NEVER RUNS — file stays open
f.close()

with open("data.txt") as f:
    data = f.read()
    process(data)   # even if this raises, the file is still closed correctly
# f.close() has already happened automatically here

class Timer:
    def __enter__(self):
        import time
        self.start = time.time()
        return self            # this becomes the value bound by "as"

    def __exit__(self, exc_type, exc_value, traceback):
        import time
        elapsed = time.time() - self.start
        print(f"Elapsed: {elapsed:.3f}s")
        return False            # False = don't suppress any exception (see Part 03)

with Timer() as t:
    total = sum(range(10_000_000))
# Elapsed: 0.412s   <- printed automatically when the block ends

class BadLogger:
    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        if exc_type is not None:
            print(f"Something went wrong: {exc_value}")
        return True    # DANGER: this SUPPRESSES the exception entirely!

with BadLogger():
    result = 10 / 0    # ZeroDivisionError happens...
print("Program continues normally")
# Something went wrong: division by zero
# Program continues normally     <- the exception was silently swallowed, "result" was NEVER assigned!

from contextlib import contextmanager
import time

@contextmanager
def timer():
    start = time.time()
    try:
        yield              # the "with" block's code runs here, at the yield point
    finally:
        elapsed = time.time() - start
        print(f"Elapsed: {elapsed:.3f}s")

with timer():
    total = sum(range(10_000_000))
# Elapsed: 0.412s

from contextlib import contextmanager
import os

@contextmanager
def working_directory(path):
    original = os.getcwd()
    os.chdir(path)
    try:
        yield
    finally:
        os.chdir(original)     # ALWAYS restored, even if the block raises

with working_directory("/tmp"):
    print(os.getcwd())    # /tmp
print(os.getcwd())        # back to the original directory automatically

with open("input.txt") as infile, open("output.txt", "w") as outfile:
    outfile.write(infile.read().upper())
# BOTH files are guaranteed closed here, even if writing raised an exception

with db.connection() as conn, conn.lock():
    conn.execute("UPDATE accounts SET balance = balance - 100 WHERE id = 1")
# The lock is released first, THEN the connection is closed — reverse of entry order

A checkout service starts returning "connection pool exhausted" errors under normal traffic. Investigation traces it to a function that manually acquires a database connection and releases it at the end — but a validation check earlier in the function occasionally raises an exception on malformed cart data, skipping the release call entirely.

def checkout(cart):
    conn = pool.acquire()
    validate_cart(cart)          # raises ValueError on malformed data — happens under real traffic
    conn.execute("INSERT INTO orders ...")
    pool.release(conn)           # NEVER REACHED if validate_cart raised — connection leaks

def checkout(cart):
    with pool.connection() as conn:     # pool.connection() is a context manager wrapping acquire/release
        validate_cart(cart)
        conn.execute("INSERT INTO orders ...")
    # conn is released here NO MATTER WHAT — including if validate_cart raised

Why manual acquire/release is considered a code smell in review

Every manually paired "acquire resource / release resource" pattern has exactly this failure mode: any code between the two calls that can raise an exception silently skips the release. The connection pool itself already exposed a context-manager-based pool.connection() for precisely this reason — reviewers at this company now flag any manual acquire()/release() pairing on sight, since a with-based alternative almost always already exists or can be written in a few lines using contextlib.contextmanager.