If you have written any Python code beyond print("Hello, World!"), you have almost certainly used a context manager — likely without even realizing it. The with statement is one of Python's most elegant features, and understanding how to write your own context managers will level up your code in terms of readability, safety, and resource management.
What Problem Do Context Managers Solve?
Consider the old-school way of reading a file:
f = open("data.txt", "r")
content = f.read()
f.close()
This looks fine — until an exception occurs between open and close. When that happens, f.close() never runs, and the file handle stays open. On a small script you might not notice, but in a long-running server or batch processor, leaked file descriptors accumulate and eventually crash your application.
The naive fix is a try/finally block:
f = open("data.txt", "r")
try:
content = f.read()
finally:
f.close()
This works, but it's verbose and easy to forget. Context managers make this pattern effortless:
with open("data.txt", "r") as f:
content = f.read()
The file is guaranteed to close — even if an exception occurs inside the block. Clean, concise, safe.
How Context Managers Work Under the Hood
A context manager is any object that implements two special methods:
| Method | Purpose | Called When |
|---|---|---|
__enter__(self) |
Set up the resource | Entering the with block |
__exit__(self, exc_type, exc_val, exc_tb) |
Tear down / clean up | Leaving the with block (normally or via exception) |
Here is the lifecycle in detail:
class MyContext:
def __enter__(self):
print("1. Entering context")
return self
def __exit__(self, exc_type, exc_val, exc_tb):
print("2. Exiting context")
if exc_type is not None:
print(f" Exception caught: {exc_type.__name__}: {exc_val}")
return False # Do NOT suppress the exception
with MyContext() as ctx:
print("3. Inside the block")
Running this prints:
1. Entering context
3. Inside the block
2. Exiting context
The three parameters passed to __exit__ are:
-
exc_type: The exception class (orNoneif no exception) -
exc_val: The exception instance (orNone) -
exc_tb: The traceback object (orNone)
If __exit__ returns True, the exception is suppressed — execution continues as if nothing happened. Return False (the default) and the exception propagates normally. Suppressing exceptions is rarely a good idea; only do it when you have explicitly handled the error.
Writing Your First Custom Context Manager
Let's build a timer that measures how long a block of code takes to execute:
import time
class Timer:
def __enter__(self):
self.start = time.perf_counter()
return self
def __exit__(self, exc_type, exc_val, exc_tb):
self.elapsed = time.perf_counter() - self.start
print(f"Elapsed: {self.elapsed:.4f}s")
return False
with Timer() as t:
total = sum(range(10_000_000))
print(f"Timer recorded {t.elapsed:.4f}s externally too")
This pattern is useful for profiling, benchmarking, and logging. Notice that we store elapsed as an attribute on self, so it is accessible even after the with block exits.
Database Connection Example
A more practical example: managing database connections:
import sqlite3
class DatabaseConnection:
def __init__(self, db_path):
self.db_path = db_path
def __enter__(self):
self.conn = sqlite3.connect(self.db_path)
return self.conn
def __exit__(self, exc_type, exc_val, exc_tb):
if exc_type is None:
self.conn.commit()
else:
self.conn.rollback()
self.conn.close()
return False
# Usage
with DatabaseConnection("app.db") as conn:
conn.execute("INSERT INTO users (name) VALUES (?)", ("Alice",))
This automatically commits on success, rolls back on failure, and always closes the connection.
The contextlib Module: Context Managers Without Classes
Python's standard library provides contextlib, which includes helpers that make creating context managers even easier. The most useful is contextmanager — a decorator that turns a generator function into a context manager:
from contextlib import contextmanager
@contextmanager
def timer():
start = time.perf_counter()
try:
yield
finally:
elapsed = time.perf_counter() - start
print(f"Elapsed: {elapsed:.4f}s")
with timer():
total = sum(range(10_000_000))
The code before yield runs as __enter__, the code after yield runs as __exit__. The try/finally ensures cleanup happens even if an exception occurs inside the block.
You can also yield a value:
@contextmanager
def open_file(path, mode):
f = open(path, mode)
try:
yield f
finally:
f.close()
with open_file("hello.txt", "w") as f:
f.write("Hello, context manager!")
This is essentially what the built-in open() context manager does.
Advanced: Context Manager for Temporary Directory Changes
Here is a useful real-world pattern: temporarily change the working directory and restore it afterward:
import os
from contextlib import contextmanager
@contextmanager
def working_directory(path):
original_cwd = os.getcwd()
os.chdir(path)
try:
yield
finally:
os.chdir(original_cwd)
with working_directory("/tmp"):
print("Current dir:", os.getcwd()) # /tmp
print("Back to:", os.getcwd()) # original
This is incredibly useful for scripts that need to operate in different directories without permanently altering the process state.
Common Pitfalls and Best Practices
| Pitfall | Why It Is Dangerous | Better Approach |
|---|---|---|
| Suppressing exceptions by accident | Returning True from __exit__ hides bugs |
Always return False unless you have a specific reason |
Forgetting yield in @contextmanager
|
The generator never yields, causing a runtime error | Always include a try/finally wrapper |
| Using a context manager on a shared mutable object | The setup/teardown may conflict with other uses | Create a new context manager instance per with block |
Heavy work inside __enter__
|
Blocks the caller until setup is complete | Defer heavy initialization to the with block itself |
Nesting Multiple Context Managers
You can nest context managers in multiple ways:
# Nested (works but can get deeply indented)
with open("a.txt") as f1:
with open("b.txt") as f2:
content = f1.read() + f2.read()
# Single with statement (Python 3.1+)
with open("a.txt") as f1, open("b.txt") as f2:
content = f1.read() + f2.read()
# Using contextlib.ExitStack (Python 3.3+) for dynamic numbers
from contextlib import ExitStack
filenames = ["a.txt", "b.txt", "c.txt"]
with ExitStack() as stack:
files = [stack.enter_context(open(f)) for f in filenames]
content = "".join(f.read() for f in files)
ExitStack is particularly powerful when you do not know at write-time how many resources you will need.
Async Context Managers
Python 3.7+ supports asynchronous context managers with __aenter__ and __aexit__:
import asyncio
class AsyncDatabase:
async def __aenter__(self):
self.conn = await connect_to_db()
return self.conn
async def __aexit__(self, exc_type, exc_val, exc_tb):
await self.conn.close()
return False
async def main():
async with AsyncDatabase() as db:
result = await db.query("SELECT 1")
asyncio.run(main())
The contextlib module also provides asynccontextmanager for the generator-based approach.
Real-World Example: Automating Server Maintenance
Here is a context manager I use regularly for Linux server maintenance. It creates a timestamped log file, runs operations, and rotates logs automatically:
from contextlib import contextmanager
import os
from datetime import datetime
@contextmanager
def maintenance_log(service_name):
log_dir = f"/var/log/maintenance/{service_name}"
os.makedirs(log_dir, exist_ok=True)
timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
log_path = os.path.join(log_dir, f"{timestamp}.log")
with open(log_path, "w") as log:
log.write(f"=== Maintenance: {service_name} ===\n")
log.write(f"Started: {timestamp}\n\n")
try:
yield log
log.write(f"\nStatus: SUCCESS\n")
except Exception as e:
log.write(f"\nStatus: FAILED - {e}\n")
raise
finally:
log.write(f"Completed: {datetime.now().strftime('%Y%m%d_%H%M%S')}\n")
# Rotate: keep only last 10 logs
logs = sorted(os.listdir(log_dir))
for old_log in logs[:-10]:
os.remove(os.path.join(log_dir, old_log))
# Usage
with maintenance_log("nginx-reload") as log:
log.write("Checking nginx config...\n")
result = os.system("nginx -t")
if result != 0:
raise RuntimeError("nginx config test failed")
log.write("Reloading nginx...\n")
os.system("systemctl reload nginx")
This pattern keeps a clean audit trail of every maintenance action and prevents log directories from growing indefinitely — exactly the kind of resource management problem context managers solve beautifully.
Final Thoughts
Context managers are a cornerstone of clean Python code. They encapsulate the setup/teardown pattern so you never have to worry about resource leaks, forgotten cleanup, or exception safety. Once you start writing your own, you will find opportunities to use them everywhere — database connections, locks, temporary files, environment variable overrides, and configuration changes.
The key takeaways:
- Use the
withstatement for any resource that needs cleanup - Write custom context managers with either the class-based approach or
@contextmanager - Never suppress exceptions unless you have a deliberate reason
- Use
ExitStackwhen dealing with a dynamic number of resources - Prefer
@contextmanagerfor simple cases and classes for complex ones
Start small — write a timer, wrap a file operation, or manage a temporary state change. Once you feel the pattern click, you will see context managers everywhere, and your code will be safer and more readable for it.
Top comments (0)