contextlib
— Utilities forwith
-statement contexts¶
Source code:Lib/contextlib.py
This module provides utilities for common tasks involving thewith
statement. For more information see alsoContext Manager Types andWith Statement Context Managers.
Utilities¶
Functions and classes provided:
- classcontextlib.AbstractContextManager¶
Anabstract base class for classes that implement
object.__enter__()
andobject.__exit__()
. A defaultimplementation forobject.__enter__()
is provided which returnsself
whileobject.__exit__()
is an abstract method which by defaultreturnsNone
. See also the definition ofContext Manager Types.Added in version 3.6.
- classcontextlib.AbstractAsyncContextManager¶
Anabstract base class for classes that implement
object.__aenter__()
andobject.__aexit__()
. A defaultimplementation forobject.__aenter__()
is provided which returnsself
whileobject.__aexit__()
is an abstract method which by defaultreturnsNone
. See also the definition ofAsynchronous Context Managers.Added in version 3.7.
- @contextlib.contextmanager¶
This function is adecorator that can be used to define a factoryfunction for
with
statement context managers, without needing tocreate a class or separate__enter__()
and__exit__()
methods.While many objects natively support use in with statements, sometimes aresource needs to be managed that isn’t a context manager in its own right,and doesn’t implement a
close()
method for use withcontextlib.closing
.An abstract example would be the following to ensure correct resourcemanagement:
fromcontextlibimportcontextmanager@contextmanagerdefmanaged_resource(*args,**kwds):# Code to acquire resource, e.g.:resource=acquire_resource(*args,**kwds)try:yieldresourcefinally:# Code to release resource, e.g.:release_resource(resource)
The function can then be used like this:
>>>withmanaged_resource(timeout=3600)asresource:...# Resource is released at the end of this block,...# even if code in the block raises an exception
The function being decorated must return agenerator-iterator whencalled. This iterator must yield exactly one value, which will be bound tothe targets in the
with
statement’sas
clause, if any.At the point where the generator yields, the block nested in the
with
statement is executed. The generator is then resumed after the block is exited.If an unhandled exception occurs in the block, it is reraised inside thegenerator at the point where the yield occurred. Thus, you can use atry
…except
…finally
statement to trapthe error (if any), or ensure that some cleanup takes place. If an exception istrapped merely in order to log it or to perform some action (rather than tosuppress it entirely), the generator must reraise that exception. Otherwise thegenerator context manager will indicate to thewith
statement thatthe exception has been handled, and execution will resume with the statementimmediately following thewith
statement.contextmanager()
usesContextDecorator
so the context managersit creates can be used as decorators as well as inwith
statements.When used as a decorator, a new generator instance is implicitly created oneach function call (this allows the otherwise “one-shot” context managerscreated bycontextmanager()
to meet the requirement that contextmanagers support multiple invocations in order to be used as decorators).Changed in version 3.2:Use of
ContextDecorator
.
- @contextlib.asynccontextmanager¶
Similar to
contextmanager()
, but creates anasynchronous context manager.This function is adecorator that can be used to define a factoryfunction for
asyncwith
statement asynchronous context managers,without needing to create a class or separate__aenter__()
and__aexit__()
methods. It must be applied to anasynchronousgenerator function.A simple example:
fromcontextlibimportasynccontextmanager@asynccontextmanagerasyncdefget_connection():conn=awaitacquire_db_connection()try:yieldconnfinally:awaitrelease_db_connection(conn)asyncdefget_all_users():asyncwithget_connection()asconn:returnconn.query('SELECT ...')
Added in version 3.7.
Context managers defined with
asynccontextmanager()
can be usedeither as decorators or withasyncwith
statements:importtimefromcontextlibimportasynccontextmanager@asynccontextmanagerasyncdeftimeit():now=time.monotonic()try:yieldfinally:print(f'it took{time.monotonic()-now}s to run')@timeit()asyncdefmain():# ... async code ...
When used as a decorator, a new generator instance is implicitly created oneach function call. This allows the otherwise “one-shot” context managerscreated by
asynccontextmanager()
to meet the requirement that contextmanagers support multiple invocations in order to be used as decorators.Changed in version 3.10:Async context managers created with
asynccontextmanager()
canbe used as decorators.
- contextlib.closing(thing)¶
Return a context manager that closesthing upon completion of the block. Thisis basically equivalent to:
fromcontextlibimportcontextmanager@contextmanagerdefclosing(thing):try:yieldthingfinally:thing.close()
And lets you write code like this:
fromcontextlibimportclosingfromurllib.requestimporturlopenwithclosing(urlopen('https://www.python.org'))aspage:forlineinpage:print(line)
without needing to explicitly close
page
. Even if an error occurs,page.close()
will be called when thewith
block is exited.Note
Most types managing resources support thecontext manager protocol,which closesthing on leaving the
with
statement.As such,closing()
is most useful for third party types that don’tsupport context managers.This example is purely for illustration purposes,asurlopen()
would normally be used in a context manager.
- contextlib.aclosing(thing)¶
Return an async context manager that calls the
aclose()
method ofthingupon completion of the block. This is basically equivalent to:fromcontextlibimportasynccontextmanager@asynccontextmanagerasyncdefaclosing(thing):try:yieldthingfinally:awaitthing.aclose()
Significantly,
aclosing()
supports deterministic cleanup of asyncgenerators when they happen to exit early bybreak
or anexception. For example:fromcontextlibimportaclosingasyncwithaclosing(my_generator())asvalues:asyncforvalueinvalues:ifvalue==42:break
This pattern ensures that the generator’s async exit code is executed inthe same context as its iterations (so that exceptions and contextvariables work as expected, and the exit code isn’t run after thelifetime of some task it depends on).
Added in version 3.10.
- contextlib.nullcontext(enter_result=None)¶
Return a context manager that returnsenter_result from
__enter__
, butotherwise does nothing. It is intended to be used as a stand-in for anoptional context manager, for example:defmyfunction(arg,ignore_exceptions=False):ifignore_exceptions:# Use suppress to ignore all exceptions.cm=contextlib.suppress(Exception)else:# Do not ignore any exceptions, cm has no effect.cm=contextlib.nullcontext()withcm:# Do something
An example usingenter_result:
defprocess_file(file_or_path):ifisinstance(file_or_path,str):# If string, open filecm=open(file_or_path)else:# Caller is responsible for closing filecm=nullcontext(file_or_path)withcmasfile:# Perform processing on the file
It can also be used as a stand-in forasynchronous context managers:
asyncdefsend_http(session=None):ifnotsession:# If no http session, create it with aiohttpcm=aiohttp.ClientSession()else:# Caller is responsible for closing the sessioncm=nullcontext(session)asyncwithcmassession:# Send http requests with session
Added in version 3.7.
Changed in version 3.10:asynchronous context manager support was added.
- contextlib.suppress(*exceptions)¶
Return a context manager that suppresses any of the specified exceptionsif they occur in the body of a
with
statement and thenresumes execution with the first statement following the end of thewith
statement.As with any other mechanism that completely suppresses exceptions, thiscontext manager should be used only to cover very specific errors wheresilently continuing with program execution is known to be the rightthing to do.
For example:
fromcontextlibimportsuppresswithsuppress(FileNotFoundError):os.remove('somefile.tmp')withsuppress(FileNotFoundError):os.remove('someotherfile.tmp')
This code is equivalent to:
try:os.remove('somefile.tmp')exceptFileNotFoundError:passtry:os.remove('someotherfile.tmp')exceptFileNotFoundError:pass
This context manager isreentrant.
If the code within the
with
block raises aBaseExceptionGroup
, suppressed exceptions are removed from thegroup. Any exceptions of the group which are not suppressed are re-raised ina new group which is created using the original group’sderive()
method.Added in version 3.4.
Changed in version 3.12:
suppress
now supports suppressing exceptions raised aspart of aBaseExceptionGroup
.
- contextlib.redirect_stdout(new_target)¶
Context manager for temporarily redirecting
sys.stdout
toanother file or file-like object.This tool adds flexibility to existing functions or classes whose outputis hardwired to stdout.
For example, the output of
help()
normally is sent tosys.stdout.You can capture that output in a string by redirecting the output to anio.StringIO
object. The replacement stream is returned from the__enter__
method and so is available as the target of thewith
statement:withredirect_stdout(io.StringIO())asf:help(pow)s=f.getvalue()
To send the output of
help()
to a file on disk, redirect the outputto a regular file:withopen('help.txt','w')asf:withredirect_stdout(f):help(pow)
To send the output of
help()
tosys.stderr:withredirect_stdout(sys.stderr):help(pow)
Note that the global side effect on
sys.stdout
means that thiscontext manager is not suitable for use in library code and most threadedapplications. It also has no effect on the output of subprocesses.However, it is still a useful approach for many utility scripts.This context manager isreentrant.
Added in version 3.4.
- contextlib.redirect_stderr(new_target)¶
Similar to
redirect_stdout()
but redirectingsys.stderr
to another file or file-like object.This context manager isreentrant.
Added in version 3.5.
- contextlib.chdir(path)¶
Non parallel-safe context manager to change the current working directory.As this changes a global state, the working directory, it is not suitablefor use in most threaded or async contexts. It is also not suitable for mostnon-linear code execution, like generators, where the program execution istemporarily relinquished – unless explicitly desired, you should not yieldwhen this context manager is active.
This is a simple wrapper around
chdir()
, it changes the currentworking directory upon entering and restores the old one on exit.This context manager isreentrant.
Added in version 3.11.
- classcontextlib.ContextDecorator¶
A base class that enables a context manager to also be used as a decorator.
Context managers inheriting from
ContextDecorator
have to implement__enter__
and__exit__
as normal.__exit__
retains its optionalexception handling even when used as a decorator.ContextDecorator
is used bycontextmanager()
, so you get thisfunctionality automatically.Example of
ContextDecorator
:fromcontextlibimportContextDecoratorclassmycontext(ContextDecorator):def__enter__(self):print('Starting')returnselfdef__exit__(self,*exc):print('Finishing')returnFalse
The class can then be used like this:
>>>@mycontext()...deffunction():...print('The bit in the middle')...>>>function()StartingThe bit in the middleFinishing>>>withmycontext():...print('The bit in the middle')...StartingThe bit in the middleFinishing
This change is just syntactic sugar for any construct of the following form:
deff():withcm():# Do stuff
ContextDecorator
lets you instead write:@cm()deff():# Do stuff
It makes it clear that the
cm
applies to the whole function, rather thanjust a piece of it (and saving an indentation level is nice, too).Existing context managers that already have a base class can be extended byusing
ContextDecorator
as a mixin class:fromcontextlibimportContextDecoratorclassmycontext(ContextBaseClass,ContextDecorator):def__enter__(self):returnselfdef__exit__(self,*exc):returnFalse
Note
As the decorated function must be able to be called multiple times, theunderlying context manager must support use in multiple
with
statements. If this is not the case, then the original construct with theexplicitwith
statement inside the function should be used.Added in version 3.2.
- classcontextlib.AsyncContextDecorator¶
Similar to
ContextDecorator
but only for asynchronous functions.Example of
AsyncContextDecorator
:fromasyncioimportrunfromcontextlibimportAsyncContextDecoratorclassmycontext(AsyncContextDecorator):asyncdef__aenter__(self):print('Starting')returnselfasyncdef__aexit__(self,*exc):print('Finishing')returnFalse
The class can then be used like this:
>>>@mycontext()...asyncdeffunction():...print('The bit in the middle')...>>>run(function())StartingThe bit in the middleFinishing>>>asyncdeffunction():...asyncwithmycontext():...print('The bit in the middle')...>>>run(function())StartingThe bit in the middleFinishing
Added in version 3.10.
- classcontextlib.ExitStack¶
A context manager that is designed to make it easy to programmaticallycombine other context managers and cleanup functions, especially thosethat are optional or otherwise driven by input data.
For example, a set of files may easily be handled in a single withstatement as follows:
withExitStack()asstack:files=[stack.enter_context(open(fname))forfnameinfilenames]# 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
The
__enter__()
method returns theExitStack
instance, andperforms no additional operations.Each instance maintains a stack of registered callbacks that are called inreverse order when the instance is closed (either explicitly or implicitlyat the end of a
with
statement). Note that callbacks arenotinvoked implicitly when the context stack instance is garbage collected.This stack model is used so that context managers that acquire theirresources in their
__init__
method (such as file objects) can behandled correctly.Since registered callbacks are invoked in the reverse order ofregistration, this ends up behaving as if multiple nested
with
statements had been used with the registered set of callbacks. This evenextends to exception handling - if an inner callback suppresses or replacesan exception, then outer callbacks will be passed arguments based on thatupdated state.This is a relatively low level API that takes care of the details ofcorrectly unwinding the stack of exit callbacks. It provides a suitablefoundation for higher level context managers that manipulate the exitstack in application specific ways.
Added in version 3.3.
- enter_context(cm)¶
Enters a new context manager and adds its
__exit__()
method tothe callback stack. The return value is the result of the contextmanager’s own__enter__()
method.These context managers may suppress exceptions just as they normallywould if used directly as part of a
with
statement.Changed in version 3.11:Raises
TypeError
instead ofAttributeError
ifcmis not a context manager.
- push(exit)¶
Adds a context manager’s
__exit__()
method to the callback stack.As
__enter__
isnot invoked, this method can be used to coverpart of an__enter__()
implementation with a context manager’s own__exit__()
method.If passed an object that is not a context manager, this method assumesit is a callback with the same signature as a context manager’s
__exit__()
method and adds it directly to the callback stack.By returning true values, these callbacks can suppress exceptions thesame way context manager
__exit__()
methods can.The passed in object is returned from the function, allowing thismethod to be used as a function decorator.
- callback(callback,/,*args,**kwds)¶
Accepts an arbitrary callback function and arguments and adds it tothe callback stack.
Unlike the other methods, callbacks added this way cannot suppressexceptions (as they are never passed the exception details).
The passed in callback is returned from the function, allowing thismethod to be used as a function decorator.
- pop_all()¶
Transfers the callback stack to a fresh
ExitStack
instanceand returns it. No callbacks are invoked by this operation - instead,they will now be invoked when the new stack is closed (eitherexplicitly or implicitly at the end of awith
statement).For example, a group of files can be opened as an “all or nothing”operation as follows:
withExitStack()asstack:files=[stack.enter_context(open(fname))forfnameinfilenames]# Hold onto the close method, but don't call it yet.close_files=stack.pop_all().close# If opening any file fails, all previously opened files will be# closed automatically. If all files are opened successfully,# they will remain open even after the with statement ends.# close_files() can then be invoked explicitly to close them all.
- close()¶
Immediately unwinds the callback stack, invoking callbacks in thereverse order of registration. For any context managers and exitcallbacks registered, the arguments passed in will indicate that noexception occurred.
- classcontextlib.AsyncExitStack¶
Anasynchronous context manager, similarto
ExitStack
, that supports combining both synchronous andasynchronous context managers, as well as having coroutines forcleanup logic.The
close()
method is not implemented;aclose()
must be usedinstead.- asyncenter_async_context(cm)¶
Similar to
ExitStack.enter_context()
but expects an asynchronous contextmanager.Changed in version 3.11:Raises
TypeError
instead ofAttributeError
ifcmis not an asynchronous context manager.
- push_async_exit(exit)¶
Similar to
ExitStack.push()
but expects either an asynchronous context manageror a coroutine function.
- push_async_callback(callback,/,*args,**kwds)¶
Similar to
ExitStack.callback()
but expects a coroutine function.
- asyncaclose()¶
Similar to
ExitStack.close()
but properly handles awaitables.
Continuing the example for
asynccontextmanager()
:asyncwithAsyncExitStack()asstack:connections=[awaitstack.enter_async_context(get_connection())foriinrange(5)]# All opened connections will automatically be released at the end of# the async with statement, even if attempts to open a connection# later in the list raise an exception.
Added in version 3.7.
Examples and Recipes¶
This section describes some examples and recipes for making effective use ofthe tools provided bycontextlib
.
Supporting a variable number of context managers¶
The primary use case forExitStack
is the one given in the classdocumentation: supporting a variable number of context managers and othercleanup operations in a singlewith
statement. The variabilitymay come from the number of context managers needed being driven by userinput (such as opening a user specified collection of files), or fromsome of the context managers being optional:
withExitStack()asstack:forresourceinresources:stack.enter_context(resource)ifneed_special_resource():special=acquire_special_resource()stack.callback(release_special_resource,special)# Perform operations that use the acquired resources
As shown,ExitStack
also makes it quite easy to usewith
statements to manage arbitrary resources that don’t natively support thecontext management protocol.
Catching exceptions from__enter__
methods¶
It is occasionally desirable to catch exceptions from an__enter__
method implementation,without inadvertently catching exceptions fromthewith
statement body or the context manager’s__exit__
method. By usingExitStack
the steps in the context managementprotocol can be separated slightly in order to allow this:
stack=ExitStack()try:x=stack.enter_context(cm)exceptException:# handle __enter__ exceptionelse:withstack:# Handle normal case
Actually needing to do this is likely to indicate that the underlying APIshould be providing a direct resource management interface for use withtry
/except
/finally
statements, but notall APIs are well designed in that regard. When a context manager is theonly resource management API provided, thenExitStack
can make iteasier to handle various situations that can’t be handled directly in awith
statement.
Cleaning up in an__enter__
implementation¶
As noted in the documentation ofExitStack.push()
, thismethod can be useful in cleaning up an already allocated resource if latersteps in the__enter__()
implementation fail.
Here’s an example of doing this for a context manager that accepts resourceacquisition and release functions, along with an optional validation function,and maps them to the context management protocol:
fromcontextlibimportcontextmanager,AbstractContextManager,ExitStackclassResourceManager(AbstractContextManager):def__init__(self,acquire_resource,release_resource,check_resource_ok=None):self.acquire_resource=acquire_resourceself.release_resource=release_resourceifcheck_resource_okisNone:defcheck_resource_ok(resource):returnTrueself.check_resource_ok=check_resource_ok@contextmanagerdef_cleanup_on_error(self):withExitStack()asstack:stack.push(self)yield# The validation check passed and didn't raise an exception# Accordingly, we want to keep the resource, and pass it# back to our callerstack.pop_all()def__enter__(self):resource=self.acquire_resource()withself._cleanup_on_error():ifnotself.check_resource_ok(resource):msg="Failed validation for{!r}"raiseRuntimeError(msg.format(resource))returnresourcedef__exit__(self,*exc_details):# We don't need to duplicate any of our resource release logicself.release_resource()
Replacing any use oftry-finally
and flag variables¶
A pattern you will sometimes see is atry-finally
statement with a flagvariable to indicate whether or not the body of thefinally
clause shouldbe executed. In its simplest form (that can’t already be handled just byusing anexcept
clause instead), it looks something like this:
cleanup_needed=Truetry:result=perform_operation()ifresult:cleanup_needed=Falsefinally:ifcleanup_needed:cleanup_resources()
As with anytry
statement based code, this can cause problems fordevelopment and review, because the setup code and the cleanup code can endup being separated by arbitrarily long sections of code.
ExitStack
makes it possible to instead register a callback forexecution at the end of awith
statement, and then later decide to skipexecuting that callback:
fromcontextlibimportExitStackwithExitStack()asstack:stack.callback(cleanup_resources)result=perform_operation()ifresult:stack.pop_all()
This allows the intended cleanup behaviour to be made explicit up front,rather than requiring a separate flag variable.
If a particular application uses this pattern a lot, it can be simplifiedeven further by means of a small helper class:
fromcontextlibimportExitStackclassCallback(ExitStack):def__init__(self,callback,/,*args,**kwds):super().__init__()self.callback(callback,*args,**kwds)defcancel(self):self.pop_all()withCallback(cleanup_resources)ascb:result=perform_operation()ifresult:cb.cancel()
If the resource cleanup isn’t already neatly bundled into a standalonefunction, then it is still possible to use the decorator form ofExitStack.callback()
to declare the resource cleanup inadvance:
fromcontextlibimportExitStackwithExitStack()asstack:@stack.callbackdefcleanup_resources():...result=perform_operation()ifresult:stack.pop_all()
Due to the way the decorator protocol works, a callback functiondeclared this way cannot take any parameters. Instead, any resources tobe released must be accessed as closure variables.
Using a context manager as a function decorator¶
ContextDecorator
makes it possible to use a context manager inboth an ordinarywith
statement and also as a function decorator.
For example, it is sometimes useful to wrap functions or groups of statementswith a logger that can track the time of entry and time of exit. Rather thanwriting both a function decorator and a context manager for the task,inheriting fromContextDecorator
provides both capabilities in asingle definition:
fromcontextlibimportContextDecoratorimportlogginglogging.basicConfig(level=logging.INFO)classtrack_entry_and_exit(ContextDecorator):def__init__(self,name):self.name=namedef__enter__(self):logging.info('Entering:%s',self.name)def__exit__(self,exc_type,exc,exc_tb):logging.info('Exiting:%s',self.name)
Instances of this class can be used as both a context manager:
withtrack_entry_and_exit('widget loader'):print('Some time consuming activity goes here')load_widget()
And also as a function decorator:
@track_entry_and_exit('widget loader')defactivity():print('Some time consuming activity goes here')load_widget()
Note that there is one additional limitation when using context managersas function decorators: there’s no way to access the return value of__enter__()
. If that value is needed, then it is still necessary to usean explicitwith
statement.
Single use, reusable and reentrant context managers¶
Most context managers are written in a way that means they can only beused effectively in awith
statement once. These single usecontext managers must be created afresh each time they’re used -attempting to use them a second time will trigger an exception orotherwise not work correctly.
This common limitation means that it is generally advisable to createcontext managers directly in the header of thewith
statementwhere they are used (as shown in all of the usage examples above).
Files are an example of effectively single use context managers, sincethe firstwith
statement will close the file, preventing anyfurther IO operations using that file object.
Context managers created usingcontextmanager()
are also single usecontext managers, and will complain about the underlying generator failingto yield if an attempt is made to use them a second time:
>>>fromcontextlibimportcontextmanager>>>@contextmanager...defsingleuse():...print("Before")...yield...print("After")...>>>cm=singleuse()>>>withcm:...pass...BeforeAfter>>>withcm:...pass...Traceback (most recent call last):...RuntimeError:generator didn't yield
Reentrant context managers¶
More sophisticated context managers may be “reentrant”. These contextmanagers can not only be used in multiplewith
statements,but may also be usedinside awith
statement that is alreadyusing the same context manager.
threading.RLock
is an example of a reentrant context manager, as aresuppress()
,redirect_stdout()
, andchdir()
. Here’s a verysimple example of reentrant use:
>>>fromcontextlibimportredirect_stdout>>>fromioimportStringIO>>>stream=StringIO()>>>write_to_stream=redirect_stdout(stream)>>>withwrite_to_stream:...print("This is written to the stream rather than stdout")...withwrite_to_stream:...print("This is also written to the stream")...>>>print("This is written directly to stdout")This is written directly to stdout>>>print(stream.getvalue())This is written to the stream rather than stdoutThis is also written to the stream
Real world examples of reentrancy are more likely to involve multiplefunctions calling each other and hence be far more complicated than thisexample.
Note also that being reentrant isnot the same thing as being thread safe.redirect_stdout()
, for example, is definitely not thread safe, as itmakes a global modification to the system state by bindingsys.stdout
to a different stream.
Reusable context managers¶
Distinct from both single use and reentrant context managers are “reusable”context managers (or, to be completely explicit, “reusable, but notreentrant” context managers, since reentrant context managers are alsoreusable). These context managers support being used multiple times, butwill fail (or otherwise not work correctly) if the specific context managerinstance has already been used in a containing with statement.
threading.Lock
is an example of a reusable, but not reentrant,context manager (for a reentrant lock, it is necessary to usethreading.RLock
instead).
Another example of a reusable, but not reentrant, context manager isExitStack
, as it invokesall currently registered callbackswhen leaving any with statement, regardless of where those callbackswere added:
>>>fromcontextlibimportExitStack>>>stack=ExitStack()>>>withstack:...stack.callback(print,"Callback: from first context")...print("Leaving first context")...Leaving first contextCallback: from first context>>>withstack:...stack.callback(print,"Callback: from second context")...print("Leaving second context")...Leaving second contextCallback: from second context>>>withstack:...stack.callback(print,"Callback: from outer context")...withstack:...stack.callback(print,"Callback: from inner context")...print("Leaving inner context")...print("Leaving outer context")...Leaving inner contextCallback: from inner contextCallback: from outer contextLeaving outer context
As the output from the example shows, reusing a single stack object acrossmultiple with statements works correctly, but attempting to nest themwill cause the stack to be cleared at the end of the innermost withstatement, which is unlikely to be desirable behaviour.
Using separateExitStack
instances instead of reusing a singleinstance avoids that problem:
>>>fromcontextlibimportExitStack>>>withExitStack()asouter_stack:...outer_stack.callback(print,"Callback: from outer context")...withExitStack()asinner_stack:...inner_stack.callback(print,"Callback: from inner context")...print("Leaving inner context")...print("Leaving outer context")...Leaving inner contextCallback: from inner contextLeaving outer contextCallback: from outer context