Showing content from http://mail.python.org/pipermail/python-dev/attachments/20170822/f79f6ed1/attachment.html below:
<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Mon, Aug 21, 2017 at 5:12 PM, Nick Coghlan </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 August 2017 at 15:03, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> Honestly I'm not sure we need the distinction between LC and EC. If you read<br>
> carefully some of the given example code seems to confuse them. If we could<br>
> get away with only a single framework-facing concept, I would be happy<br>
> calling it ExecutionContext.<br>
<br>
</span>Unfortunately, I don't think we can, and that's why I tried to reframe<br>
the discussion in terms of "Where ContextKey.set() writes to" and<br>
"Where ContextKey.get() looks things up".<br>
<br>
Consider the following toy generator:<br>
<br>
  def tracking_gen():<br>
    start_tracking_iterations()<br>
    while True:<br>
      tally_iteration()<br>
      yield<br>
<br>
  task_id = ContextKey("task_id")<br>
  iter_counter = ContextKey("iter_counter")<br>
<br>
  def start_tracking_iterations():<br>
    iter_counter.set(collection.<wbr>Counter())<br>
<br>
  def tally_iteration():<br>
    current_task = task_id.get() # Set elsewhere<br>
    iter_counter.get()[current_<wbr>task] += 1<br>
<br>
Now, this isn't a very *sensible* generator (since it could just use a<br>
regular object instance for tracking instead of a context variable),<br>
but nevertheless, it's one that we would expect to work, and it's one<br>
that we would expect to exhibit the following properties:<br>
<br>
1. When tally_iteration() calls task_id.get(), we expect that to be<br>
resolved in the context calling next() on the instance, *not* the<br>
context where the generator was first created<br>
2. When tally_iteration() calls iter_counter.get(), we expect that to<br>
be resolved in the same context where start_tracking_iterations()<br>
called iter_counter.set()<br>
<br>
This has consequences for the design in the PEP:<br>
<br>
* what we want to capture at generator creation time is the context<br>
where writes will happen, and we also want that to be the innermost<br>
context used for lookups<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">â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?</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">â-- Koosâ<br></div></div><div><br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* other than that innermost context, we want everything else to be dynamic<br>
* this means that "mutable context saved on the generator" and "entire<br>
dynamic context visible when the generator runs" aren't the same thing<br>
<br>
And hence the introduction of the LocalContext/LogicalContext<br>
terminology for the former, and the ExecutionContext terminology for<br>
the latter.<br>
<br><br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">â[...]â</div>Â </div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4