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

Ethan Furman ethan at stoneleaf.us
Sun Aug 20 04🔞13 EDT 2017

On 08/19/2017 10:41 PM, Nick Coghlan wrote:

On 20 August 2017 at 10:21, Guido van Rossum wrote:

The way we came to "logical context" was via "logical thread (of control)", which is distinct from OS thread. But I think we might need to search for another term... Right. Framing it in pragmatic terms, the two entities that we're attempting to name are: 1. The mutable storage that ContextKey.set() writes to 2. The dynamic context that ContextKey.get() queries Right now, we're using ExecutionContext for the latter, and LogicalContext for the former, and I can definitely see Antoine's point that those names don't inherently convey any information about which is which.

[snip]

# Replacing ExecutionContext in the current PEP DynamicQueryContext sys.getdynamicquerycontext() sys.newdynamicquerycontext() sys.runwithdynamicquerycontext() # Suggests immutability -> good! # Suggests connection to ck.get() -> good!

# Replacing LogicalContext in the current PEP ExecutionContext sys.newexecutioncontext() sys.runwithexecutioncontext() executioncontext attribute on generators (et al) # Neutral on mutability/immutability # Neutral on ck.set()/ck.get()

[snippety snip]

# Replacing ExecutionContext in the current PEP DynamicQueryContext sys.getquerycontext() sys.newquerycontext() sys.runwithquerycontext() # Suggests immutability -> good! # Suggests connection to ck.get() -> good!

# Replacing LogicalContext in the current PEP DynamicWriteContext sys.newwritecontext() sys.runwithwritecontext() writecontext attribute on generators (et al) # Suggests mutability -> good! # Suggests connection to ck.set() -> good!

This is just getting more confusing for me.

Going back to Yury's original names for now...

Relating this naming problem back to globals() and locals(), the correlation works okay for locals/LocalContext, but breaks down at the globals() level because globals() is a specific set of variables -- namely, module-level assignments, while ExecutionContext would be the equivalent of globals, nonlocals, and locals all together.

A more accurate name for ExecutionContext might be ParentContext, but that would imply that the LocalContext is not included, and it is (if I finally understand what's going on, of course).

So I like ExecutionContext for the stack of WhateverWeCallTheOtherContext contexts. But what do we call it? Again, if I understand what's going on, a normal, threadless, non-async, generator-bereft, plain vanilla Python program is going to have only one LocalContext no matter how many nor how deep the function call chain goes -- so in that sense Local isn't really the best word, but Context all by itself is /really/ unhelpful, and Local does imply "the most current Context Layer".

Of all the names proposed so far, I think LocalContext is the best reminder of the thing that CK.key writes to. For the piled layers of LocalContexts that CK.key.get searches through, either ExecutionContext or perhaps ContextEnvironment or even ContextStack works for me (the stack portion not being an implementation detail, but a promise of how it effectively works).

-- Ethan

More information about the Python-Dev mailing list