[Python-Dev] PEP 567 v2 (original) (raw)

Victor Stinner victor.stinner at gmail.com
Wed Jan 3 18:44:10 EST 2018

Ok, I finally got access to a computer and I was able to test the PEP 567 implementation: see my code snippet below.

The behaviour is more tricky than what I expected. While running context.run(), the context object is out of sync of the "current context". It's only synchronized again at run() exit. So ContextVar.set() doesn't immediately modifies the "current context" object (set by Context.run()).

Ok, and now something completely different! What if Context looses its whole mapping API and becomes a "blackbox" object only with a run() method and no attribute? It can be documented as an object mapping context variables to their values, but don't give access to these values directly. It would avoid to have explain the weird run() behaviour (context out of sync). It would avoid to have to decide if it's a mutable or immutable mapping. It would avoid to have to explain the internal O(1) copy using HAMT.

Code testing Context.run():

import contextvars

name = contextvars.ContextVar('name', default='name')

def assertNotIn(var, context): try: context[var] except LookupError: pass else: raise AssertionError("name is set is context")

def func1(): name.set('yury') assert name.get() == 'yury' assertNotIn(name, context)

def func2(): assert name.get() == 'yury' assert context[name] == 'yury'

context = contextvars.copy_context()

assert name.get() == 'name' assertNotIn(name, context)

context.run(func1)

assert name.get() == 'name' assert context[name] == 'yury'

context.run(func2)

assert name.get() == 'name' assert context[name] == 'yury'

Victor

More information about the Python-Dev mailing list