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

Koos Zevenhoven k7hoven at gmail.com
Mon Aug 21 17:14:46 EDT 2017

On Mon, Aug 21, 2017 at 5:12 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 21 August 2017 at 15:03, Guido van Rossum <guido at 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 trackinggen(): starttrackingiterations() while True: tallyiteration() yield taskid = ContextKey("taskid") itercounter = ContextKey("itercounter") def starttrackingiterations(): itercounter.set(collection.Counter()) def tallyiteration(): currenttask = taskid.get() # Set elsewhere itercounter.get()[currenttask] += 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 tallyiteration() calls taskid.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 tallyiteration() calls itercounter.get(), we expect that to be resolved in the same context where starttrackingiterations() called itercounter.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.

​[...]​

--

More information about the Python-Dev mailing list