Regular Single-threaded Code

In regular, single-threaded code that doesn’t involve generators orcoroutines, context variables behave like globals:

var=contextvars.ContextVar('var')defsub():assertvar.get()=='main'var.set('sub')defmain():var.set('main')sub()assertvar.get()=='sub'

Multithreaded Code

In multithreaded code, context variables behave like thread locals:

var=contextvars.ContextVar('var')defsub():assertvar.get()isNone# The execution context is empty# for each new thread.var.set('sub')defmain():var.set('main')thread=threading.Thread(target=sub)thread.start()thread.join()assertvar.get()=='main'

Generators

Unlike regular function calls, generators can cooperatively yieldtheir control of execution to the caller. Furthermore, a generatordoes not controlwhere the execution would continue after it yields.It may be resumed from an arbitrary code location.

For these reasons, the least surprising behaviour of generators isas follows:

• changes to context variables are always local and are not visiblein the outer context, but are visible to the code called by thegenerator;
• once set in the generator, the context variable is guaranteed notto change between iterations;
• changes to context variables in outer context (where the generatoris being iterated) are visible to the generator, unless thesevariables were also modified inside the generator.

Let’s review:

var1=contextvars.ContextVar('var1')var2=contextvars.ContextVar('var2')defgen():var1.set('gen')assertvar1.get()=='gen'assertvar2.get()=='main'yield1# Modification to var1 in main() is shielded by# gen()'s local modification.assertvar1.get()=='gen'# But modifications to var2 are visibleassertvar2.get()=='main modified'yield2defmain():g=gen()var1.set('main')var2.set('main')next(g)# Modification of var1 in gen() is not visible.assertvar1.get()=='main'var1.set('main modified')var2.set('main modified')next(g)

Now, let’s revisit the decimal precision example from theRationalesection, and see how the execution context can improve the situation:

importdecimal# create a new context vardecimal_ctx=contextvars.ContextVar('decimal context')# Pre-PEP 550 Decimal relies on TLS for its context.# For illustration purposes, we monkey-patch the decimal# context functions to use the execution context.# A real working fix would need to properly update the# C implementation as well.defpatched_setcontext(context):decimal_ctx.set(context)defpatched_getcontext():ctx=decimal_ctx.get()ifctxisNone:ctx=decimal.Context()decimal_ctx.set(ctx)returnctxdecimal.setcontext=patched_setcontextdecimal.getcontext=patched_getcontextdeffractions(precision,x,y):withdecimal.localcontext()asctx:ctx.prec=precisionyieldMyDecimal(x)/MyDecimal(y)yieldMyDecimal(x)/MyDecimal(y**2)g1=fractions(precision=2,x=1,y=3)g2=fractions(precision=6,x=2,y=3)items=list(zip(g1,g2))

The value ofitems is:

[(Decimal('0.33'),Decimal('0.666667')),(Decimal('0.11'),Decimal('0.222222'))]

which matches the expected result.

Coroutines and Asynchronous Tasks

Like generators, coroutines can yield and regain control. The majordifference from generators is that coroutines do not yield to theimmediate caller. Instead, the entire coroutine call stack(coroutines chained byawait) switches to another coroutine callstack. In this regard,await-ing on a coroutine is conceptuallysimilar to a regular function call, and a coroutine chain(or a “task”, e.g. anasyncio.Task) is conceptually similar to athread.

From this similarity we conclude that context variables in coroutinesshould behave like “task locals”:

• changes to context variables in a coroutine are visible to thecoroutine that awaits on it;
• changes to context variables made in the caller prior to awaitingare visible to the awaited coroutine;
• changes to context variables made in one task are not visible inother tasks;
• tasks spawned by other tasks inherit the execution context from theparent task, but any changes to context variables made in theparent taskafter the child task was spawned arenot visible.

The last point shows behaviour that is different from OS threads.OS threads do not inherit the execution context by default.There are two reasons for this:common usage intent and backwardscompatibility.

The main reason for why tasks inherit the context, and threads donot, is the common usage intent. Tasks are often used for relativelyshort-running operations which are logically tied to the code thatspawned the task (like running a coroutine with a timeout inasyncio). OS threads, on the other hand, are normally used forlong-running, logically separate code.

With respect to backwards compatibility, we want the execution contextto behave likethreading.local(). This is so that libraries canstart using the execution context in place of TLS with a lesser riskof breaking compatibility with existing code.

Let’s review a few examples to illustrate the semantics we have justdefined.

Context variable propagation in a single task:

importasynciovar=contextvars.ContextVar('var')asyncdefmain():var.set('main')awaitsub()# The effect of sub() is visible.assertvar.get()=='sub'asyncdefsub():assertvar.get()=='main'var.set('sub')assertvar.get()=='sub'loop=asyncio.get_event_loop()loop.run_until_complete(main())

Context variable propagation between tasks:

importasynciovar=contextvars.ContextVar('var')asyncdefmain():var.set('main')loop.create_task(sub())# schedules asynchronous execution# of sub().assertvar.get()=='main'var.set('main changed')asyncdefsub():# Sleeping will make sub() run after# "var" is modified in main().awaitasyncio.sleep(1)# The value of "var" is inherited from main(), but any# changes to "var" made in main() after the task# was created are *not* visible.assertvar.get()=='main'# This change is local to sub() and will not be visible# to other tasks, including main().var.set('sub')loop=asyncio.get_event_loop()loop.run_until_complete(main())

As shown above, changes to the execution context are local to thetask, and tasks get a snapshot of the execution context at the pointof creation.

There is one narrow edge case when this can lead to surprisingbehaviour. Consider the following example where we modify thecontext variable in a nested coroutine:

asyncdefsub(var_value):awaitasyncio.sleep(1)var.set(var_value)asyncdefmain():var.set('main')# waiting for sub() directlyawaitsub('sub-1')# var change is visibleassertvar.get()=='sub-1'# waiting for sub() with a timeout;awaitasyncio.wait_for(sub('sub-2'),timeout=2)# wait_for() creates an implicit task, which isolates# context changes, which means that the below assertion# will fail.assertvar.get()=='sub-2'#  AssertionError!

However, relying on context changes leaking to the caller isultimately a bad pattern. For this reason, the behaviour shown inthe above example is not considered a major issue and can beaddressed with proper documentation.

Generators

When created, each generator object has an empty logical contextobject stored in its__logical_context__ attribute. This logicalcontext is pushed onto the execution context at the beginning of eachgenerator iteration and popped at the end:

var1=contextvars.ContextVar('var1')var2=contextvars.ContextVar('var2')defgen():var1.set('var1-gen')var2.set('var2-gen')# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen', var2: 'var2-gen'})# ]n=nested_gen()# nested_gen_LC is creatednext(n)# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen', var2: 'var2-gen'})# ]var1.set('var1-gen-mod')var2.set('var2-gen-mod')# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen-mod', var2: 'var2-gen-mod'})# ]next(n)defnested_gen():# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen', var2: 'var2-gen'}),#     nested_gen_LC()# ]assertvar1.get()=='var1-gen'assertvar2.get()=='var2-gen'var1.set('var1-nested-gen')# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen', var2: 'var2-gen'}),#     nested_gen_LC({var1: 'var1-nested-gen'})# ]yield# EC = [#     outer_LC(),#     gen_LC({var1: 'var1-gen-mod', var2: 'var2-gen-mod'}),#     nested_gen_LC({var1: 'var1-nested-gen'})# ]assertvar1.get()=='var1-nested-gen'assertvar2.get()=='var2-gen-mod'yield# EC = [outer_LC()]g=gen()# gen_LC is created for the generator object `g`list(g)# EC = [outer_LC()]

The snippet above shows the state of the execution context stackthroughout the generator lifespan.

contextlib.contextmanager

Thecontextlib.contextmanager() decorator can be used to turna generator into a context manager. A context manager thattemporarily modifies the value of a context variable could be definedlike this:

var=contextvars.ContextVar('var')@contextlib.contextmanagerdefvar_context(value):original_value=var.get()try:var.set(value)yieldfinally:var.set(original_value)

Unfortunately, this would not work straight away, as the modificationto thevar variable is contained to thevar_context()generator, and therefore will not be visible inside thewithblock:

deffunc():# EC = [{}, {}]withvar_context(10):# EC becomes [{}, {}, {var: 10}] in the# *precision_context()* generator,# but here the EC is still [{}, {}]assertvar.get()==10# AssertionError!

The way to fix this is to set the generator’s__logical_context__attribute toNone. This will cause the generator to avoidmodifying the execution context stack.

We modify thecontextlib.contextmanager() decorator tosetgenobj.__logical_context__ toNone to producewell-behaved context managers:

deffunc():# EC = [{}, {}]withvar_context(10):# EC = [{}, {var: 10}]assertvar.get()==10# EC becomes [{}, {var: None}]

Enumerating context vars

TheExecutionContext.vars() method returns a list ofContextVar objects, that have values in the execution context.This method is mostly useful for introspection and logging.

coroutines

In CPython, coroutines share the implementation with generators.The difference is that in coroutines__logical_context__ defaultstoNone. This affects both theasyncdef coroutines and theold-style generator-based coroutines (generators decorated with@types.coroutine).

Asynchronous Generators

The execution context semantics in asynchronous generators does notdiffer from that of regular generators.

asyncio

asyncio usesLoop.call_soon,Loop.call_later,andLoop.call_at to schedule the asynchronous execution of afunction.asyncio.Task usescall_soon() to run thewrapped coroutine.

We modifyLoop.call_{at,later,soon} to accept the newoptionalexecution_context keyword argument, which defaults tothe copy of the current execution context:

defcall_soon(self,callback,*args,execution_context=None):ifexecution_contextisNone:execution_context=contextvars.get_execution_context()# ... some time latercontextvars.run_with_execution_context(execution_context,callback,args)

Thecontextvars.get_execution_context() function returns ashallow copy of the current execution context. By shallow copy herewe mean such a new execution context that:

• lookups in the copy provide the same results as in the originalexecution context, and
• any changes in the original execution context do not affect thecopy, and
• any changes to the copy do not affect the original executioncontext.

Either of the following satisfy the copy requirements:

• a new stack with shallow copies of logical contexts;
• a new stack with one squashed logical context.

Thecontextvars.run_with_execution_context(ec,func,*args,**kwargs) function runsfunc(*args,**kwargs) withec as theexecution context. The function performs the following steps:

1. Setec as the current execution context stack in the currentthread.
2. Push an empty logical context onto the stack.
3. Runfunc(*args,**kwargs).
4. Pop the logical context from the stack.
5. Restore the original execution context stack.
6. Return or raise thefunc() result.

These steps ensure thatec cannot be modified byfunc,which makesrun_with_execution_context() idempotent.

asyncio.Task is modified as follows:

classTask:def__init__(self,coro):...# Get the current execution context snapshot.self._exec_context=contextvars.get_execution_context()# Create an empty Logical Context that will be# used by coroutines run in the task.coro.__logical_context__=contextvars.LogicalContext()self._loop.call_soon(self._step,execution_context=self._exec_context)def_step(self,exc=None):...self._loop.call_soon(self._step,execution_context=self._exec_context)...

Generators Transformed into Iterators

Any Python generator can be represented as an equivalent iterator.Compilers like Cython rely on this axiom. With respect to theexecution context, such iterator should behave the same way as thegenerator it represents.

This means that there needs to be a Python API to create new logicalcontexts and run code with a given logical context.

Thecontextvars.LogicalContext() function creates a new emptylogical context.

Thecontextvars.run_with_logical_context(lc,func,*args,**kwargs) function can be used to run functions in the specifiedlogical context. Thelc can be modified as a result of the call.

Thecontextvars.run_with_logical_context() function performs thefollowing steps:

1. Pushlc onto the current execution context stack.
2. Runfunc(*args,**kwargs).
3. Poplc from the execution context stack.
4. Return or raise thefunc() result.

By usingLogicalContext() andrun_with_logical_context(),we can replicate the generator behaviour like this:

classGenerator:def__init__(self):self.logical_context=contextvars.LogicalContext()def__iter__(self):returnselfdef__next__(self):returncontextvars.run_with_logical_context(self.logical_context,self._next_impl)def_next_impl(self):# Actual __next__ implementation....

Let’s see how this pattern can be applied to an example generator:

# create a new context variablevar=contextvars.ContextVar('var')defgen_series(n):var.set(10)foriinrange(1,n):yieldvar.get()*i# gen_series is equivalent to the following iterator:classCompiledGenSeries:# This class is what the `gen_series()` generator can# be transformed to by a compiler like Cython.def__init__(self,n):# Create a new empty logical context,# like the generators do.self.logical_context=contextvars.LogicalContext()# Initialize the generator in its LC.# Otherwise `var.set(10)` in the `_init` method# would leak.contextvars.run_with_logical_context(self.logical_context,self._init,n)def_init(self,n):self.i=1self.n=nvar.set(10)def__iter__(self):returnselfdef__next__(self):# Run the actual implementation of __next__ in our LC.returncontextvars.run_with_logical_context(self.logical_context,self._next_impl)def_next_impl(self):ifself.i==self.n:raiseStopIterationresult=var.get()*self.iself.i+=1returnresult

For hand-written iterators such approach to context management isnormally not necessary, and it is easier to set and restorecontext variables directly in__next__:

classMyIterator:# ...def__next__(self):old_val=var.get()try:var.set(new_val)# ...finally:var.set(old_val)

Logical Context

Logical context is an immutable weak key mapping which has thefollowing properties with respect to garbage collection:

• ContextVar objects are strongly-referenced only from theapplication code, not from any of the execution context machineryor values they point to. This means that there are no referencecycles that could extend their lifespan longer than necessary, orprevent their collection by the GC.
• Values put in the execution context are guaranteed to be keptalive while there is aContextVar key referencing them inthe thread.
• If aContextVar is garbage collected, all of its values willbe removed from all contexts, allowing them to be GCed if needed.
• If an OS thread has ended its execution, its thread state will becleaned up along with its execution context, cleaningup all values bound to all context variables in the thread.

As discussed earlier, we needcontextvars.get_execution_context()to be consistently fast regardless of the size of the executioncontext, so logical context is necessarily an immutable mapping.

Choosingdict for the underlying implementation is suboptimal,becauseLC.set() will causedict.copy(), which is an O(N)operation, whereN is the number of items in the LC.

get_execution_context(), when squashing the EC, is an O(M)operation, whereM is the total number of context variable valuesin the EC.

So, instead ofdict, we choose Hash Array Mapped Trie (HAMT)as the underlying implementation of logical contexts. (Scala andClojure use HAMT to implement high performance immutable collections[5],[6].)

With HAMT.set() becomes an O(log N) operation, andget_execution_context() squashing is more efficient on average dueto structural sharing in HAMT.

SeeAppendix: HAMT Performance Analysis for a more elaborateanalysis of HAMT performance compared todict.

Context Variables

TheContextVar.get() andContextVar.set() methods areimplemented as follows (in pseudo-code):

classContextVar:defget(self,*,default=None,topmost=False):tstate=PyThreadState_Get()ec_node=tstate.ecwhileec_node:ifselfinec_node.lc:returnec_node.lc[self]iftopmost:breakec_node=ec_node.prevreturndefaultdefset(self,value):tstate=PyThreadState_Get()top_ec_node=tstate.eciftop_ec_nodeisnotNone:top_lc=top_ec_node.lcnew_top_lc=top_lc.set(self,value)tstate.ec=ec_node(prev=top_ec_node.prev,lc=new_top_lc)else:# First ContextVar.set() in this OS thread.top_lc=contextvars.LogicalContext()new_top_lc=top_lc.set(self,value)tstate.ec=ec_node(prev=NULL,lc=new_top_lc)defdelete(self):tstate=PyThreadState_Get()top_ec_node=tstate.eciftop_ec_nodeisNone:raiseLookupErrortop_lc=top_ec_node.lcifselfnotintop_lc:raiseLookupErrornew_top_lc=top_lc.delete(self)tstate.ec=ec_node(prev=top_ec_node.prev,lc=new_top_lc)

For efficient access in performance-sensitive code paths, such as innumpy anddecimal, we cache lookups inContextVar.get(),making it an O(1) operation when the cache is hit. The cache key iscomposed from the following:

• The newuint64_tPyThreadState->unique_id, which is a globallyunique thread state identifier. It is computed from the newuint64_tPyInterpreterState->ts_counter, which is incrementedwhenever a new thread state is created.
• The newuint64_tPyThreadState->stack_version, which is athread-specific counter, which is incremented whenever a non-emptylogical context is pushed onto the stack or popped from the stack.
• Theuint64_tContextVar->version counter, which is incrementedwhenever the context variable value is changed in any logicalcontext in any OS thread.

The cache is then implemented as follows:

classContextVar:defset(self,value):...# implementationself.version+=1defget(self,*,default=None,topmost=False):iftopmost:returnself._get_uncached(default=default,topmost=topmost)tstate=PyThreadState_Get()if(self.last_tstate_id==tstate.unique_idandself.last_stack_ver==tstate.stack_versionandself.last_version==self.version):returnself.last_valuevalue=self._get_uncached(default=default)self.last_value=value# borrowed refself.last_tstate_id=tstate.unique_idself.last_stack_version=tstate.stack_versionself.last_version=self.versionreturnvalue

Note thatlast_value is a borrowed reference. We assume thatif the version checks are fine, the value object will be alive.This allows the values of context variables to be properly garbagecollected.

This generic caching approach is similar to what the current Cimplementation ofdecimal does to cache the current decimalcontext, and has similar performance characteristics.

Python

The following new Python APIs are introduced by this PEP:

1. The newcontextvars.ContextVar(name:str='...') class,instances of which have the following:
   • the read-only.name attribute,
   • the.get() method, which returns the value of the variablein the current execution context;
   • the.set() method, which sets the value of the variable inthe current logical context;
   • the.delete() method, which removes the value of the variablefrom the current logical context.
2. The newcontextvars.ExecutionContext() class, which representsan execution context.
3. The newcontextvars.LogicalContext() class, which representsa logical context.
4. The newcontextvars.get_execution_context() function, whichreturns anExecutionContext instance representing a copy ofthe current execution context.
5. Thecontextvars.run_with_execution_context(ec:ExecutionContext,func,*args,**kwargs) function, which runsfunc with theprovided execution context.
6. Thecontextvars.run_with_logical_context(lc:LogicalContext,func,*args,**kwargs) function, which runsfunc with theprovided logical context on top of the current execution context.

C API

1. PyContextVar*PyContext_NewVar(char*desc): create aPyContextVar object.
2. PyObject*PyContext_GetValue(PyContextVar*,inttopmost):return the value of the variable in the current execution context.
3. intPyContext_SetValue(PyContextVar*,PyObject*): setthe value of the variable in the current logical context.
4. intPyContext_DelValue(PyContextVar*): delete the value ofthe variable from the current logical context.
5. PyLogicalContext*PyLogicalContext_New(): create a new emptyPyLogicalContext.
6. PyExecutionContext*PyExecutionContext_New(): create a newemptyPyExecutionContext.
7. PyExecutionContext*PyExecutionContext_Get(): return thecurrent execution context.
8. intPyContext_SetCurrent(PyExecutionContext*,PyLogicalContext*): set thepassed EC object as the current execution context for the activethread state, and/or set the passed LC object as the currentlogical context.

Should “yield from” leak context changes?

No. It may be argued thatyieldfrom is semanticallyequivalent to calling a function, and should leak context changes.However, it is not possible to satisfy the following at the same time:

• next(gen)does not leak context changes made ingen, and
• yieldfromgenleaks context changes made ingen.

The reason is thatyieldfrom can be used with a partiallyiterated generator, which already has local context changes:

var=contextvars.ContextVar('var')defgen():foriinrange(10):var.set('gen')yieldidefouter_gen():var.set('outer_gen')g=gen()yieldnext(g)# Changes not visible during partial iteration,# the goal of this PEP:assertvar.get()=='outer_gen'yield fromgassertvar.get()=='outer_gen'# or 'gen'?

Another example would be refactoring of an explicitfor..inyieldconstruct to ayieldfrom expression. Consider the followingcode:

defouter_gen():var.set('outer_gen')foriingen():yieldiassertvar.get()=='outer_gen'

which we want to refactor to useyieldfrom:

defouter_gen():var.set('outer_gen')yield fromgen()assertvar.get()=='outer_gen'# or 'gen'?

The above examples illustrate that it is unsafe to refactorgenerator code usingyieldfrom when it can leak context changes.

Thus, the only well-defined and consistent behaviour is toalways isolate context changes in generators, regardless ofhow they are being iterated.

ShouldPyThreadState_GetDict() use the execution context?

No.PyThreadState_GetDict is based on TLS, and changing itssemantics will break backwards compatibility.

PEP 521

PEP 521 proposes an alternative solution to the problem, whichextends the context manager protocol with two new methods:__suspend__() and__resume__(). Similarly, the asynchronouscontext manager protocol is also extended with__asuspend__() and__aresume__().

This allows implementing context managers that manage non-local state,which behave correctly in generators and coroutines.

For example, consider the following context manager, which usesexecution state:

classContext:def__init__(self):self.var=contextvars.ContextVar('var')def__enter__(self):self.old_x=self.var.get()self.var.set('something')def__exit__(self,*err):self.var.set(self.old_x)

An equivalent implementation withPEP 521:

local=threading.local()classContext:def__enter__(self):self.old_x=getattr(local,'x',None)local.x='something'def__suspend__(self):local.x=self.old_xdef__resume__(self):local.x='something'def__exit__(self,*err):local.x=self.old_x

The downside of this approach is the addition of significant newcomplexity to the context manager protocol and the interpreterimplementation. This approach is also likely to negatively impactthe performance of generators and coroutines.

Additionally, the solution inPEP 521 is limited to contextmanagers, and does not provide any mechanism to propagate state inasynchronous tasks and callbacks.

Can Execution Context be implemented without modifying CPython?

No.

It is true that the concept of “task-locals” can be implementedfor coroutines in libraries (see, for example,[29] and[30]).On the other hand, generators are managed by the Python interpreterdirectly, and so their context must also be managed by theinterpreter.

Furthermore, execution context cannot be implemented in a third-partymodule at all, otherwise the standard library, includingdecimalwould not be able to rely on it.

Should we update sys.displayhook and other APIs to use EC?

APIs like redirecting stdout by overwritingsys.stdout, orspecifying new exception display hooks by overwriting thesys.displayhook function are affecting the whole Python processby design. Their users assume that the effect of changingthem will be visible across OS threads. Therefore, we cannotjust make these APIs to use the new Execution Context.

That said we think it is possible to design new APIs that willbe context aware, but that is outside of the scope of this PEP.

Greenlets

Greenlet is an alternative implementation of cooperativescheduling for Python. Although greenlet package is not part ofCPython, popular frameworks like gevent rely on it, and it isimportant that greenlet can be modified to support executioncontexts.

Conceptually, the behaviour of greenlets is very similar to that ofgenerators, which means that similar changes around greenlet entryand exit can be done to add support for execution context. ThisPEP provides the necessary C APIs to do that.

Context manager as the interface for modifications

This PEP concentrates on the low-level mechanics and the minimalAPI that enables fundamental operations with execution context.

For developer convenience, a high-level context manager interfacemay be added to thecontextvars module. For example:

withcontextvars.set_var(var,'foo'):# ...

Setting and restoring context variables

TheContextVar.delete() method removes the context variable fromthe topmost logical context.

If the variable is not found in the topmost logical context, aLookupError is raised, similarly todelvar raisingNameError whenvar is not in scope.

This method is useful when there is a (rare) need to correctly restorethe state of a logical context, such as when a nested generatorwants to modify the logical contexttemporarily:

var=contextvars.ContextVar('var')defgen():withsome_var_context_manager('gen'):# EC = [{var: 'main'}, {var: 'gen'}]assertvar.get()=='gen'yield# EC = [{var: 'main modified'}, {}]assertvar.get()=='main modified'yielddefmain():var.set('main')g=gen()next(g)var.set('main modified')next(g)

The above example would work correctly only if there is a way todeletevar from the logical context ingen(). Setting itto a “previous value” in__exit__() would mask changes madeinmain() between the iterations.

Alternative Designs for ContextVar API

var=contextvars.ContextVar('var')deffoo():mod=var.set('spam')# ... perform workmod.reset()# Reset the value of var to the original value# or remove it from the context.

Replication of threading.local() interface

Choosing thethreading.local()-like interface for contextvariables was considered and rejected for the following reasons:

• A survey of the standard library and Django has shown that thevast majority ofthreading.local() uses involve a singleattribute, which indicates that the namespace approach is notas helpful in the field.
• Using__getattr__() instead of.get() for value lookupdoes not provide any way to specify the depth of the lookup(i.e. search only the top logical context).
• Single-valueContextVar is easier to reason about in termsof visibility. SupposeContextVar() is a namespace,and the consider the following:

  ns=contextvars.ContextVar('ns')defgen():ns.a=2yieldassertns.b=='bar'# ??defmain():ns.a=1ns.b='foo'g=gen()next(g)# should not see the ns.a modification in gen()assertns.a==1# but should gen() see the ns.b modification made here?ns.b='bar'yield

  The above example demonstrates that reasoning about the visibilityof different attributes of the same context var is not trivial.

• Single-valueContextVar allows straightforward implementationof the lookup cache;
• Single-valueContextVar interface allows the C-API to besimple and essentially the same as the Python API.

See also the mailing list discussion:[26],[27].

Coroutines not leaking context changes by default

In V4 (Version History) of this PEP, coroutines were considered tobehave exactly like generators with respect to the execution context:changes in awaited coroutines were not visible in the outer coroutine.

This idea was rejected on the grounds that is breaks the semanticsimilarity of the task and thread models, and, more specifically,makes it impossible to reliably implement asynchronous contextmanagers that modify context vars, since__aenter__ is acoroutine.