On Mon, Aug 21, 2017 at 5:12 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 August 2017 at 15:03, Guido van Rossum <guido@python.org> wrote:
> Honestly I'm not sure we need the distinction between LC and EC. If you read
> carefully some of the given example code seems to confuse them. If we could
> get away with only a single framework-facing concept, I would be happy
> calling it ExecutionContext.

Unfortunately, I don't think we can, and that's why I tried to reframe
the discussion in terms of "Where ContextKey.set() writes to" and
"Where ContextKey.get() looks things up".

Consider the following toy generator:

    def tracking_gen():
        start_tracking_iterations()
        while True:
            tally_iteration()
            yield

    task_id = ContextKey("task_id")
    iter_counter = ContextKey("iter_counter")

    def start_tracking_iterations():
        iter_counter.set(collection.Counter())

    def tally_iteration():
        current_task = task_id.get() # Set elsewhere
        iter_counter.get()[current_task] += 1

Now, this isn't a very *sensible* generator (since it could just use a
regular object instance for tracking instead of a context variable),
but nevertheless, it's one that we would expect to work, and it's one
that we would expect to exhibit the following properties:

1. When tally_iteration() calls task_id.get(), we expect that to be
resolved in the context calling next() on the instance, *not* the
context where the generator was first created
2. When tally_iteration() calls iter_counter.get(), we expect that to
be resolved in the same context where start_tracking_iterations()
called iter_counter.set()

This has consequences for the design in the PEP:

* what we want to capture at generator creation time is the context
where writes will happen, and we also want that to be the innermost
context used for lookups

​I don't get it. How is this a consequence of the above two points? And why do we need to capture something (a "context") at generator creation time?

​-- Koos​

 
* other than that innermost context, we want everything else to be dynamic
* this means that "mutable context saved on the generator" and "entire
dynamic context visible when the generator runs" aren't the same thing

And hence the introduction of the LocalContext/LogicalContext
terminology for the former, and the ExecutionContext terminology for
the latter.


​[...]​
 



--
+ Koos Zevenhoven + http://twitter.com/k7hoven +