36

We have code that invokes a variable number of context managers depending on runtime parameters:

from contextlib import nested, contextmanager

@contextmanager
def my_context(arg):
    print("entering", arg)
    try:
        yield arg
    finally:
        print("exiting", arg)

def my_fn(items): 
    with nested(*(my_context(arg) for arg in items)) as managers:
        print("processing under", managers)

my_fn(range(3))

However, contextlib.nested is deprecated since Python 2.7:

DeprecationWarning: With-statements now directly support multiple context managers

The answers to Multiple variables in Python 'with' statement indicate that contextlib.nested has some "confusing error prone quirks", but the suggested alternative of using the multiple-manager with statement won't work for a variable number of context managers (and also breaks backward compatibility).

Are there any alternatives to contextlib.nested that aren't deprecated and (preferably) don't have the same bugs?

Or should I continue to use contextlib.nested and ignore the warning? If so, should I plan for contextlib.nested to be removed at some time in the future?

Community
  • 1
  • 1
ecatmur
  • 152,476
  • 27
  • 293
  • 366
  • 2
    You raise a good point about the arbitrary number of managers ... It seems to me like that point should be raised on a mailing list somewhere... – mgilson Apr 18 '13 at 13:08
  • This is why Python 3 introduced [`contextlib.ExitStack`](http://docs.python.org/3/library/contextlib.html#contextlib.ExitStack). See http://bugs.python.org/issue13585 – Martijn Pieters Apr 18 '13 at 13:09

3 Answers3

30

The new Python 3 contextlib.ExitStack class was added as a replacement for contextlib.nested() (see issue 13585).

It is coded in such a way you can use it in Python 2 directly:

import sys
from collections import deque


class ExitStack(object):
    """Context manager for dynamic management of a stack of exit callbacks

    For example:

        with ExitStack() as stack:
            files = [stack.enter_context(open(fname)) for fname in filenames]
            # All opened files will automatically be closed at the end of
            # the with statement, even if attempts to open files later
            # in the list raise an exception

    """
    def __init__(self):
        self._exit_callbacks = deque()

    def pop_all(self):
        """Preserve the context stack by transferring it to a new instance"""
        new_stack = type(self)()
        new_stack._exit_callbacks = self._exit_callbacks
        self._exit_callbacks = deque()
        return new_stack

    def _push_cm_exit(self, cm, cm_exit):
        """Helper to correctly register callbacks to __exit__ methods"""
        def _exit_wrapper(*exc_details):
            return cm_exit(cm, *exc_details)
        _exit_wrapper.__self__ = cm
        self.push(_exit_wrapper)

    def push(self, exit):
        """Registers a callback with the standard __exit__ method signature

        Can suppress exceptions the same way __exit__ methods can.

        Also accepts any object with an __exit__ method (registering a call
        to the method instead of the object itself)
        """
        # We use an unbound method rather than a bound method to follow
        # the standard lookup behaviour for special methods
        _cb_type = type(exit)
        try:
            exit_method = _cb_type.__exit__
        except AttributeError:
            # Not a context manager, so assume its a callable
            self._exit_callbacks.append(exit)
        else:
            self._push_cm_exit(exit, exit_method)
        return exit # Allow use as a decorator

    def callback(self, callback, *args, **kwds):
        """Registers an arbitrary callback and arguments.

        Cannot suppress exceptions.
        """
        def _exit_wrapper(exc_type, exc, tb):
            callback(*args, **kwds)
        # We changed the signature, so using @wraps is not appropriate, but
        # setting __wrapped__ may still help with introspection
        _exit_wrapper.__wrapped__ = callback
        self.push(_exit_wrapper)
        return callback # Allow use as a decorator

    def enter_context(self, cm):
        """Enters the supplied context manager

        If successful, also pushes its __exit__ method as a callback and
        returns the result of the __enter__ method.
        """
        # We look up the special methods on the type to match the with statement
        _cm_type = type(cm)
        _exit = _cm_type.__exit__
        result = _cm_type.__enter__(cm)
        self._push_cm_exit(cm, _exit)
        return result

    def close(self):
        """Immediately unwind the context stack"""
        self.__exit__(None, None, None)

    def __enter__(self):
        return self

    def __exit__(self, *exc_details):
        # We manipulate the exception state so it behaves as though
        # we were actually nesting multiple with statements
        frame_exc = sys.exc_info()[1]
        def _fix_exception_context(new_exc, old_exc):
            while 1:
                exc_context = new_exc.__context__
                if exc_context in (None, frame_exc):
                    break
                new_exc = exc_context
            new_exc.__context__ = old_exc

        # Callbacks are invoked in LIFO order to match the behaviour of
        # nested context managers
        suppressed_exc = False
        while self._exit_callbacks:
            cb = self._exit_callbacks.pop()
            try:
                if cb(*exc_details):
                    suppressed_exc = True
                    exc_details = (None, None, None)
            except:
                new_exc_details = sys.exc_info()
                # simulate the stack of exceptions by setting the context
                _fix_exception_context(new_exc_details[1], exc_details[1])
                if not self._exit_callbacks:
                    raise
                exc_details = new_exc_details
        return suppressed_exc

Use this as your context manager, then add nested context managers at will:

with ExitStack() as stack:
    managers = [stack.enter_context(my_context(arg)) for arg in items]
    print("processing under", managers)

For your example context manager, this prints:

>>> my_fn(range(3))
('entering', 0)
('entering', 1)
('entering', 2)
('processing under', [0, 1, 2])
('exiting', 2)
('exiting', 1)
('exiting', 0)

You can also install the contextlib2 module; it includes ExitStack as a backport.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • This solution only works in a situation where the context managers to be used are 'entered' in the same context where they're assembled. In [this code](https://github.com/fabric/fabric/blob/master/fabric/context_managers.py#L243), for example, the result of `nested` is returned for the caller to enter later. I don't see a way to implement this in Python 3. – Jason R. Coombs Oct 01 '13 at 22:40
  • You mean you want to construct a stacked CM in a function or similar, then *later* use that stack in a `with` statement? You can do that with an `ExitStack()` too; just create an instance in a variable, use `.enter_context()` to push context managers on it, then *later* use the instance in a `with` statement. You can pass the object around just like other Python objects. – Martijn Pieters Oct 01 '13 at 22:59
  • 1
    If you want to postpone *entering* too, a subclass that takes a queue and calls `.enter_context()` on `__enter__()` (and handles exiting properly when an exception occurs) isn't too hard to write. – Martijn Pieters Oct 01 '13 at 23:04
  • The one thing you need to be wary about is that *creating* the CM can raise an exception too; so passing in callables to that queue is probably the best approach, postponing creating the CMs until `__enter__` has been called. – Martijn Pieters Oct 01 '13 at 23:10
  • Great suggestion. I was considering subclassing ExitStack to defer entering the contexts, but I wasn't sure if that was too hacky. Since you recommend it, I'm much more confident to try it. Thanks! – Jason R. Coombs Oct 02 '13 at 20:19
  • @JasonR.Coombs: the problem with `contextlib.nested()` is that you *have* to create your context managers first, before the call to `nested()`. Which means that in a list of `Foo(), Bar(), Baz()` if the *creation* of `Baz()` fails, `Foo()` and `Bar()` never have had `__enter__()` nor `__exit__()` called on them. – Martijn Pieters Oct 02 '13 at 20:22
  • @JasonR.Coombs: So a subclass of `ExitStack` should take callables that create the context manager, then call each in turn and ensure they are entered before creating the next context manager. – Martijn Pieters Oct 02 '13 at 20:22
  • 1
    I wonder why they didn't add this to recent versions of Python 2.7 as well, since `nested` is already deprecated and the code for `ExitStack` is directly usable in Python 2.7. Do you think just copying this into my project is my best bet as long as I want to support Python 2.7? – Lev Levitsky Dec 06 '13 at 12:34
  • I'd say so, yes. Import the `contextlib` version first, and if the import fails (`except ImportError:`) use this version instead. That way you'll use the stdlib version where available. – Martijn Pieters Dec 06 '13 at 12:36
  • There's now contextlib2 if you want a backport to python2. – Lucas Wiman Aug 26 '16 at 05:37
  • Note that there's `AsyncExitStack` starting in Python 3.7 in case you're using asyncio. – Gonzalo Nov 13 '19 at 13:19
  • @JasonR.Coombs wrap the entire thing in a context manager which does that, creating and filling the ExitStack on its own `__enter__`. – Masklinn Jun 03 '21 at 12:55
6

It's a little vexing that the python3 maintainers chose to break backwards compatibility, since implementing nested in terms of ExitStack is pretty straightforward:

try:
    from contextlib import nested  # Python 2
except ImportError:
    from contextlib import ExitStack, contextmanager

    @contextmanager
    def nested(*contexts):
        """
        Reimplementation of nested in python 3.
        """
        with ExitStack() as stack:
            for ctx in contexts:
                stack.enter_context(ctx)
            yield contexts
Lucas Wiman
  • 10,021
  • 2
  • 37
  • 41
  • 1
    This implementation has the same problem the original `nested` had. The context managers are already created by the time the `nested` function is called. If the constructor for a context manager at index > 0 throws an exception, the preceding context managers won't ever be exited. – Timothy Shields Sep 08 '16 at 15:50
  • 2
    It does have that "problem", yes. That's _only_ a problem for contexts which grab resources when they're constructed (as `open` does, unfortunately). There are many contexts which do not function that way, and `nested` allowed you to return a single return value which can be used as a context for all the sub-contexts. – Lucas Wiman Sep 09 '16 at 19:08
0
import sys
import contextlib

class nodeA(object):

    def __init__(self):
        print( '__init__ nodeA')

    def __enter__(self):
        print( '__enter__ nodeA')

    def __exit__(self, a, b, c):
        print( '__exit__ nodeA')

class nodeB(object):

    def __init__(self):
        print( '__init__ nodeB')

    def __enter__(self):
        print( '__enter__ nodeB')

    def __exit__(self, a, b, c):
        print( '__exit__ nodeB')

class nodeC(object):

    def __init__(self):
        print( '__init__ nodeC')

    def __enter__(self):
        print( '__enter__ nodeC')

    def __exit__(self, a, b, c):
        print( '__exit__ nodeC')

print( 'Start...')

a = nodeA()
b = nodeB()
c = nodeC()

print( 'Python version: %s' % (sys.version))

if sys.version.startswith('2'):
    print('Use python 2!')
    with contextlib.nested(a, b, c):
        print('hallo?')

if sys.version.startswith('3'):
    print('Use python 3!')
    with contextlib.ExitStack() as stack:
        [stack.enter_context(arg) for arg in [a,b,c]]

print('...end!')
Joost
  • 11