[Python-Dev] PEP 567 -- Context Variables (original) (raw)

Nathaniel Smith njs at pobox.com
Wed Dec 13 05:23:44 EST 2017

On Tue, Dec 12, 2017 at 10:39 PM, Dima Tisnek <dimaqq at gmail.com> wrote:

My 2c: TL;DR PEP specifies implementation in some detail, but doesn't show how proposed change can or should be used.

get()/set(value)/delete() methods: Python provides syntax sugar for these, let's use it. (dict: d["k"]/d["k] = value/del d["k"]; attrs: obj.k/obj.k = value/del obj.k; inheriting threading.Local)

This was already discussed to death in the PEP 550 threads... what most users want is a single value, and routing get/set through a ContextVar object allows for important optimizations and a simpler implementation. Also, remember that 99% of users will never use these objects directly; it's a low-level API mostly useful to framework implementers.

This PEP and 550 describe why TLS is inadequate, but don't seem to specify how proposed context behaves in async world. I'd be most interested in how it appears to work to the user of the new library.

Consider a case of asynchronous cache: async def actuallookup(name): ... def cachedlookup(name, cache={}): if name not in cache: cache["name"] = shield(ensurefuture(actuallookup(name)) return cache["name"] Unrelated (or related) asynchronous processes end up waiting on the same future: async def calledwithusercontext(): ... await cachedlookup(...) ... Which context is propagated to actuallookup()? The PEP doesn't seem to state that clearly. It appears to be first caller's context.

Yes.

Is it a copy or a reference?

It's a copy, as returned by get_context().

If first caller is cancelled, the context remains alive.

token is fragile, I believe PEP should propose a working context manager instead. Btw., isn't a token really a reference to state-of-context-before-it's-cloned-and-modified?

No, a Token only represents the value of one ContextVar, not the whole Context. This could maybe be clearer in the PEP, but it has to be this way or you'd get weird behavior from code like:

with decimal.localcontext(...): # sets and then restores numpy.seterr(...) # sets without any plan to restore

after the 'with' block, the decimal ContextVar gets restored

but this shouldn't affect the numpy.seterr ContextVar

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list