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.get_dynamic_query_context()
sys.new_dynamic_query_context()
sys.run_with_dynamic_query_context()
# Suggests immutability -> good!
# Suggests connection to ck.get() -> good!
# Replacing LogicalContext in the current PEP
ExecutionContext
sys.new_execution_context()
sys.run_with_execution_context()
__execution_context__ 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.get_query_context()
sys.new_query_context()
sys.run_with_query_context()
# Suggests immutability -> good!
# Suggests connection to ck.get() -> good!
# Replacing LogicalContext in the current PEP
DynamicWriteContext
sys.new_write_context()
sys.run_with_write_context()
__write_context__ 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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
