On Sat, Aug 26, 2017 at 10:25 AM, Eric Snow
With threads we have a directed graph of execution, rooted at the root thread, branching with each new thread and merging with each .join(). Each thread gets its own copy of each threading.local, regardless of the relationship between branches (threads) in the execution graph.
With async (and generators) we also have a directed graph of execution, rooted in the calling thread, branching with each new async call. Currently there is no equivalent to threading.local for the async execution graph. This proposal involves adding such an equivalent.
However, the proposed solution isn''t quite equivalent, right? It adds a concept of lookup on the chain of namespaces, traversing up the execution graph back to the root. threading.local does not do this. Furthermore, you can have more than one threading.local per thread. From what I read in the PEP, each node in the execution graph has (at most) one Execution Context.
The PEP doesn't really say much about these differences from threadlocals, including a rationale. FWIW, I think such a COW mechanism could be useful. However, it does add complexity to the feature. So a clear explanation in the PEP of why it's worth it would be valuable.
You might be interested in these notes I wrote to motivate why we need a chain of namespaces, and why simple "async task locals" aren't sufficient: https://github.com/njsmith/pep-550-notes/blob/master/dynamic-scope.ipynb They might be a bit verbose to include directly in the PEP, but Yury/Elvis, feel free to steal whatever if you think it'd be useful. -n -- Nathaniel J. Smith -- https://vorpus.org