The idea of the with
statement is to make "doing the right thing" the path of least resistance. While the file example is the simplest, threading locks actually provide a more classic example of non-obviously buggy code:
try:
lock.acquire()
# do stuff
finally:
lock.release()
This code is broken - if the lock acquisition ever fails, either the wrong exception will be thrown (since the code will attempt to release a lock that it never acquired), or, worse, if this is a recursive lock, it will be released early. The correct code looks like this:
lock.acquire()
try:
# do stuff
finally:
# If lock.acquire() fails, this *doesn't* run
lock.release()
By using a with
statement, it becomes impossible to get this wrong, since it is built into the context manager:
with lock: # The lock *knows* how to correctly handle acquisition and release
# do stuff
The other place where the with
statement helps greatly is similar to the major benefit of function and class decorators: it takes "two piece" code, which may be separated by an arbitrary number of lines of code (the function definition for decorators, the try
block in the current case) and turns it into "one piece" code where the programmer simply declares up front what they're trying to do.
For short examples, this doesn't look like a big gain, but it actually makes a huge difference when reviewing code. When I see lock.acquire()
in a piece of code, I need to scroll down and check for a corresponding lock.release()
. When I see with lock:
, though, no such check is needed - I can see immediately that the lock will be released correctly.
I don't know why no one has mentioned this yet, because it's fundamental to the way with
works. As with many language features in Python, with
behind the scenes calls special methods, which are already defined for built-in Python objects and can be overridden by user-defined classes. In with
's particular case (and context managers more generally), the methods are __enter__
and __exit__
.
Remember that in Python everything is an object -- even literals. This is why you can do things like 'hello'[0]
. Thus, it does not matter whether you use the file object directly as returned by open
:
with open('filename.txt') as infile:
for line in infile:
print(line)
or store it first with a different name (for example to break up a long line):
the_file = open('filename' + some_var + '.txt')
with the_file as infile:
for line in infile:
print(line)
Because the end result is that the_file
, infile
, and the return value of open
all point to the same object, and that's what with
is calling the __enter__
and __exit__
methods on. The built-in file object's __exit__
method is what closes the file.
Best Answer
I believe this has already been answered by other users before me, so I only add it for the sake of completeness: the
with
statement simplifies exception handling by encapsulating common preparation and cleanup tasks in so-called context managers. More details can be found in PEP 343. For instance, theopen
statement is a context manager in itself, which lets you open a file, keep it open as long as the execution is in the context of thewith
statement where you used it, and close it as soon as you leave the context, no matter whether you have left it because of an exception or during regular control flow. Thewith
statement can thus be used in ways similar to the RAII pattern in C++: some resource is acquired by thewith
statement and released when you leave thewith
context.Some examples are: opening files using
with open(filename) as fp:
, acquiring locks usingwith lock:
(wherelock
is an instance ofthreading.Lock
). You can also construct your own context managers using thecontextmanager
decorator fromcontextlib
. For instance, I often use this when I have to change the current directory temporarily and then return to where I was:Here's another example that temporarily redirects
sys.stdin
,sys.stdout
andsys.stderr
to some other file handle and restores them later:And finally, another example that creates a temporary folder and cleans it up when leaving the context: