When should I use a context manager in a small Python function?

Function size isn’t the deciding factor. Look for a bounded lifecycle: something is prepared, used within a specific part of the function, and then finalized. Python’s with statement is designed to let initialization and finalization code bracket a block [S1]. A short function can benefit if that makes the resource’s scope easier to see.

Here is the explicit version:

def read_snapshot(session_factory):
    session = session_factory()
    try:
        return session.snapshot()
    finally:
        session.close()

And the context-manager version:

def read_snapshot(session_factory):
    with session_factory() as session:
        return session.snapshot()

This comparison assumes session_factory() returns an object that supports with, and that its context-manager behavior handles the intended setup and cleanup. The with spelling alone does not make an arbitrary object a context manager. If the object has no suitable context manager, keep explicit cleanup or use an appropriate wrapper.

Check that the boundary is a real one: setup happens before the work, and cleanup belongs after it. Then check the object’s documentation or implementation to confirm it supports the context-manager protocol and that entering and leaving it have the behavior your function needs. The language reference supports the general bracketing role of with; it does not establish that any particular session library, object, or cleanup policy supports it [S1].

Also ask whether the code inside the block is the whole period during which the resource is needed. If the resource must remain available after the block, the scope is wrong. If setup and cleanup are unrelated to the block or require several distinct decisions, explicit code may communicate those decisions more clearly. Don’t switch solely to make the function shorter.

Treat the names below as placeholders, not as a built-in Python resource or a claim about a particular library. Suppose an existing object has a suitable context manager and its documented behavior matches your need:

def make_preview(resource_factory):
    with resource_factory() as resource:
        return resource.preview()

The useful shape is: acquire one resource, do the work that needs it, and leave the resource’s scope. If you currently see matching setup and cleanup around a block, that is a cue to investigate a context manager—not proof that one exists. The manager determines the actual entry and exit behavior [S1].

For example, before adopting this shape, verify what resource_factory() returns and what happens when the block finishes. If those details aren’t clear, retain the explicit version while you find out. A readable try/finally is better than assuming an unsupported cleanup contract.

Use a short review note that records the assumption instead of claiming the conversion is automatically safer:

“Assumption: resource_factory() returns a context manager whose documented exit behavior matches this function’s cleanup needs. Keep preview() inside the with block because it uses the resource. If that assumption is unverified, retain explicit cleanup.”

Then check the actual scope and behavior. A context manager is a good fit when it makes a setup/use/finalization boundary clearer and the object provides an appropriate manager [S1]. If the function has no such lifecycle, there is no need to introduce one just for style. The evidence cited here explains the purpose of with; it does not identify which third-party objects support it or establish their specific cleanup behavior.