Strange behavior with contextmanager

Question

Take a look at the following example:

from contextlib import AbstractContextManager, contextmanager


class MyClass(AbstractContextManager):
    _values = {}

    @contextmanager
    def using(self, name, value):
        print(f'Allocating {name} = {value}')
        self._values[name] = value
        try:
            yield
        finally:
            print(f'Releasing {name}')
            del self._values[name]

    def __enter__(self):
        return self.using('FOO', 42).__enter__()

    def __exit__(self, exc_type, exc_val, exc_tb):
        pass


with MyClass():
    print('Doing work...')

I would expect the above code to print the following:

Allocating FOO = 42
Doing work...
Releasing FOO

Instead, this is what is being printed:

Allocating FOO = 42
Releasing FOO
Doing work...

Why is FOO getting released eagerly?

Does this answer your question? [try-finally in Python 3 generator](https://stackoverflow.com/questions/56062909/try-finally-in-python-3-generator) — ddejohn, Nov 11 '22 at 01:00

user2357112 · Accepted Answer · 2022-11-11T01:16:58.477

3

You're creating two context managers here. Only one of those context managers is actually implemented correctly.

Your using context manager is fine, but you've also implemented the context manager protocol on MyClass itself, and the implementation on MyClass is broken. MyClass.__enter__ creates a using context manager, enters it, returns what that context manager's __enter__ returns, and then throws the using context manager away.

You don't exit the using context manager when MyClass() is exited. You never exit it at all! You throw the using context manager away. It gets reclaimed, and when it does, the generator gets close called automatically, as part of normal generator cleanup. That throws a GeneratorExit exception into the generator, triggering the finally block.

Python doesn't promise when this cleanup will happen (or indeed, if it will happen at all), but in practice, CPython's reference counting mechanism triggers the cleanup as soon as the using context manager is no longer reachable.

Aside from that, if _values is supposed to be an instance variable, it should be set as self._values = {} inside an __init__ method. Right now, it's a class variable.

edited Nov 11 '22 at 01:16

answered Nov 11 '22 at 01:02

user2357112

260,549
28
431
505

I think `_values` is supposed to be a dictionary that keeps track of different contexts via the key. But for the minimal example he just hard-coded a key. – Barmar Nov 11 '22 at 01:08
1

This answer would be improved by showing how to code it correctly. The impression I get from the documentation is that you don't normally need to write your own `__enter__` and `__exit__` when you use `@contextmanager`, it takes care of that for you. – Barmar Nov 11 '22 at 01:10
1

@Barmar: I can't tell enough about the intended use case to figure out what *would* be the "correct" way to write this. It'd probably involve getting rid of one of the context managers, but I don't know which, and there's a big difference between what the code looks like if you get rid of `using` or if you get rid of `__enter__` and `__exit__` on `MyClass`. – user2357112 Nov 11 '22 at 01:14

Strange behavior with contextmanager

1 Answers1