[Python-Dev] PEP 550 v4 (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Sat Aug 26 14:02:24 EDT 2017

Hi Eric,

On Sat, Aug 26, 2017 at 1:25 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:

Thanks for the update. Comments in-line below.

-eric On Fri, Aug 25, 2017 at 4:32 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote: [snip]

This PEP adds a new generic mechanism of ensuring consistent access to non-local state in the context of out-of-order execution, such as in Python generators and coroutines. Thread-local storage, such as threading.local(), is inadequate for programs that execute concurrently in the same OS thread. This PEP proposes a solution to this problem. [snip] In regular, single-threaded code that doesn't involve generators or coroutines, context variables behave like globals:: [snip] In multithreaded code, context variables behave like thread locals:: [snip] In generators, changes to context variables are local and are not visible to the caller, but are visible to the code called by the generator. Once set in the generator, the context variable is guaranteed not to change between iterations:: 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.

Correct.

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.

Currently, the PEP covers the proposed mechanism in-depth, explaining why every detail of the spec is the way it is. But I think it'd be valuable to highlight differences from theading.local() in a separate section. We'll think about adding one.

Yury

More information about the Python-Dev mailing list