RetroSearch Browse

Wed Jan 3 18:44:10 EST 2018 · https://mail.python.org/pipermail/python-dev/2018-January/151577.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-January/151577.html below:

[Python-Dev] PEP 567 v2