On 24 August 2017 at 08:47, Ethan Furman <ethan at stoneleaf.us> wrote: > > ContextVars is actually a different name for LogicalContext. So it would > be: > > ExecutionContext = [ContextVars()[, ContextVars()[ ...]]] > > and you get the (thread.local similar) ContextVars by > > context_vars = sys.get_context_vars() # or whatever > context_vars.verbose = ... Migrating a (variant of a) naming subthread from python-ideas over to here, does the following sound plausible to anyone else?: ContextLocal - read/write access API (via get()/set() methods) ContextLocalNamespace - active mapping that CL.get()/set() manipulates ExecutionContext - current stack of context local namespaces Building a threading.local() style helper API would then look something like: class ContextLocals: def __init__(self, key_prefix): self._key_prefix = key_prefix def __getattr__(self, attr): debugging_name = "{}.{}".format(self._key_prefix, attr) self.__dict__[attr] = new_local = sys.new_context_local(debugging_name) return new_local def __setattr__(self, attr, value): getattr(self, attr).set(value) def __delattr__(self, attr): getattr(self, attr).set(None) my_state = ContextLocals(__name__) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4