Introduction

Python's __enter__ and __exit__ methods power the with statement. They are the core of the context manager protocol, which exists to set up a resource, run a block of code, and then clean up reliably afterward. Once you understand that sequence, the methods become much less mysterious.

What the with Statement Really Does

A with block is not just shorthand for opening a file. It is a structured lifecycle.

1. Python calls __enter__ before the block starts.
2. The returned value is optionally bound after as.
3. The block runs.
4. Python calls __exit__ when the block ends, even if an exception happened.

That last step is the real value. Cleanup becomes deterministic.

__enter__ Sets Up the Context

__enter__ usually acquires or initializes the resource and returns the object that the block should use.

1class ManagedFile:
2    def __init__(self, path, mode):
3        self.path = path
4        self.mode = mode
5        self.handle = None
6
7    def __enter__(self):
8        self.handle = open(self.path, self.mode, encoding="utf-8")
9        return self.handle
10
11    def __exit__(self, exc_type, exc_value, traceback):
12        self.handle.close()
13
14with ManagedFile("example.txt", "w") as f:
15    f.write("hello\n")

Here __enter__ opens the file and returns the file handle, so f refers to that handle inside the block.

__exit__ Cleans Up and Sees Exceptions

__exit__ is always called when control leaves the with block. It receives three arguments describing any exception that occurred:

• exception type
• exception instance
• traceback object

1class LoggerContext:
2    def __enter__(self):
3        print("starting")
4        return self
5
6    def __exit__(self, exc_type, exc_value, traceback):
7        print(f"ending, exception: {exc_type}")
8
9with LoggerContext():
10    print("inside block")

If no exception occurred, those three values are None. If an exception happened, __exit__ gets the details and can react.

Returning True Suppresses an Exception

A subtle but important rule is that __exit__ can suppress an exception by returning True.

1class IgnoreValueError:
2    def __enter__(self):
3        return self
4
5    def __exit__(self, exc_type, exc_value, traceback):
6        return exc_type is ValueError
7
8with IgnoreValueError():
9    int("not-a-number")
10
11print("program continues")

This is powerful, but it should be used carefully. Accidentally swallowing exceptions can make debugging much harder.

Most Context Managers Return self or the Managed Resource

There is no universal rule about what __enter__ should return. Common choices are:

• 'self, when the manager object exposes the useful API'
• the underlying resource, such as a file handle or lock wrapper

The value should match what makes the with ... as name part easiest to use.

Context Managers Are About More Than Files

Files are the classic example, but the protocol is broader. Context managers are useful for:

• database transactions
• thread locks
• temporary configuration changes
• timing and logging scopes
• resource pooling

1import threading
2
3lock = threading.Lock()
4
5with lock:
6    print("critical section")

The pattern is always the same: enter, do work, exit.

contextlib Can Build Them More Easily

You do not always need to write a class. Python's contextlib.contextmanager decorator lets you define a context manager with a generator.

1from contextlib import contextmanager
2
3@contextmanager
4def managed_message():
5    print("enter")
6    try:
7        yield "resource"
8    finally:
9        print("exit")
10
11with managed_message() as value:
12    print(value)

This is often cleaner for small one-off contexts.

Why This Pattern Matters

Without a context manager, cleanup code often ends up repeated in try/finally blocks throughout the codebase. Context managers package that pattern into one reusable abstraction.

That makes code safer and easier to read because the setup and teardown rules live in one place.

Common Pitfalls

• Forgetting that __exit__ runs even when an exception occurs.
• Returning True from __exit__ and unintentionally swallowing real errors.
• Returning the wrong object from __enter__ and making the as variable confusing.
• Using a context manager when no real setup or teardown behavior exists.
• Reimplementing simple context patterns that contextlib already handles well.

Summary

• '__enter__ runs at the start of a with block and usually returns the usable object.'
• '__exit__ runs at the end of the block and handles cleanup.'
• '__exit__ receives exception information if the block failed.'
• Returning True from __exit__ suppresses the exception.
• Context managers are a structured way to guarantee cleanup for resources and temporary state.