Introduction to Context Managers
00:20 If the exception results in your script exiting, the operating system will typically close the file for you. But what if you catch the error somewhere else to inform the user? Well, you’ve still got an open file handle.
00:32 Your operating system has a maximum number of file handles that it will allow you to open at any given time. It typically isn’t a small number. On many Linux boxes, it defaults to just over a thousand, but if you’re executing a long-running program, lack of resource management can catch up with you.
Dad joke in the title aside, a common way of dealing with the problem is to use a
finally block. The
finally portion of the block runs whether or not there was an exception, guaranteeing that your file gets closed.
Everything indented underneath it is in the block. When the block is finished, the context manager automatically closes the file for you. This is in contrast to the
finally case. Here, you don’t have to remember to handle the resource.
It’s done by the context manager. Not having to remember is good. The downside is you don’t have an opportunity to deal with the exception. It gets caught, and the file gets closed, but you can’t inform the user like you would with the
except portion of the
Context managers are built following a protocol. They are objects, like everything in Python, and these objects need to have a
.__enter__() method, which, if it returns something, becomes the target of the
as portion of the statement, and a
.__exit__() method that is called when the context block goes out of scope.
This is where your resource closing goes. When Python hits a
with statement, it calls the context manager’s
.__enter__() method, provides the result of
.__enter__() to the
as target, runs the code block underneath the
with, and finally, once the block exits, it calls the context manager’s
Become a Member to join the conversation.