DEV Community


TIL: What Happens When Using the Context Manager Outside its with-Statement

fronkan profile image Fredrik Bengtsson ・2 min read

The other day I learned two things about context managers. The first one is that the variable, created when using with ... as x exist outside the context-block. This isn't really surprising, I just never tried it before. The second is that what happens when calling a method on the context manager outside the with-statement, really depends on the implementation. Which for some reason surprised me a lot more than it maybe should. Anyway, let us get into how I came across this.

So at work, I came across some code that I was surprised worked at all. It is related to using the flask.testing.FlaskClient as a context manager, which is shown in the tutorial: I can not share the code but I will re-create the scenario with a minimal example.

To start with I have an example Flask app, which contains the code:

from flask import Flask

app = Flask(__name__)

def hello_world():
    return "Hello World!"
Enter fullscreen mode Exit fullscreen mode

I also created the file, which I will use for a small test for the app. The file looks like this:

import pytest
import my_flask_app

def test_helloworld():
    with as client:
    resp = client.get("/")
    assert resp.get_data(as_text=True) == "Hello World!"
Enter fullscreen mode Exit fullscreen mode

If you know how context managers work, you probably can see the issue. I am using the client context variable outside the context-block. I use a pass statement here, but in reality, it was some more setup code. It was an easy mistake to make, having the wrong indentation level on a single line of code. What was so surprising is that the test actually works.

This caused me to dig around and I came across this StackOverflow question: So what is happening here is that the context manager gives you access to the request-stack inside the context but the actual communication is not affected by this. Therefore, when you exit the context the client still worked as expected for what we needed in the test.

I could contrast this with the most common context manager, the file returned from open. So what we usually do is this:

with open("my_file.txt", "r") as f:
Enter fullscreen mode Exit fullscreen mode

If we would do the read outside the context-block, like this:

with open("my_file.txt", "r") as f:
Enter fullscreen mode Exit fullscreen mode

Then we get ValueError: I/O operation on closed file., which is expected as the idea of this context manager is to automatically close the file when finished.

To summarize what I take with me from this discovery. Instead of blindly using a context manager, try to understand what context it actually sets up. Also, I think this can be a lesson for when you are designing your own context managers. Make sure the intent is well documented and think about how you want the object to behave when used outside the context. Maybe an error will be raised because a resource has been released. In that case, make sure the error message is clear and easy to understand.

Discussion (0)

Editor guide