[Python-Dev] PEP 550 v3

Nick Coghlan ncoghlan at gmail.com
Sun Aug 20 01:41:36 EDT 2017

On 20 August 2017 at 10:21, Guido van Rossum <gvanrossum at gmail.com> 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.

Personally, I still like the idea of moving ExecutionContext into the
"mutable storage" role, and then finding some other name for the stack
of execution contexts that ck.get() queries.

For example, if we named the latter after what it's *for*, we could
call it the DynamicQueryContext, and end up with the following
invocation functions:

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

    # Replacing LogicalContext in the current PEP
    __execution_context__ attribute on generators (et al)
    # Neutral on mutability/immutability
    # Neutral on ck.set()/ck.get()

An alternative would be to dispense with the ExecutionContext name
entirely, and instead use DynamicWriteContext and DynamicQueryContext.
If we did that, I'd suggest omitting "dynamic" from the function and
attribute names (while keeping it on the types), and end up with:

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

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

In this variant, the phrase "execution context" could become a general
term that covered *all* of the active state that a running piece of
code has access to (the dynamic context,  thread locals, closure
variables, module globals, process globals, etc), rather than
referring to any particular runtime entity.


P.S. Since we have LookupError (rather than QueryError) as the shared
base exception type for KeyError and IndexError, it would also be
entirely reasonable to replace "Query" in the above suggestions with
"Lookup" (DynamicLookupContext, sys.get_lookup_context(), etc). That
would also have the benefit of being less jargony, and more like
conversational English.

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list