<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 4, 2018 at 4:11 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 January 2018 at 02:15, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> On Wed, Jan 3, 2018 at 5:42 PM, Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br>
>> It seems like many people, including myself, are confused by the lack<br>
>> of concrete current context in the PEP 567 (contextvars). But it isn't<br>
>> difficult to implement the current context (I implemented it, see<br>
>> below).<br>
><br></span></blockquote><div>[Nathaniel] <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The problem with such an API is that it doesn't work (or at the very<br>
> least creates a lot of complications) in a potential future PEP 550<br>
> world, where the "current context" becomes something like a<br>
> ChainMap-of-Contexts instead of just the last Context that had run()<br>
> called on it. This isn't a big problem for contextvars.get_context(),<br>
> which returns a snapshot of the current context -- in a PEP 550 world<br>
> it would return a snapshot of the current "effective" (flattened)<br>
> context.<br>
<br></span></blockquote><div>[Paul] <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>But PEP 567 is specifically a restricted version of PEP 550 that<br>
doesn't try to solve the case of generators and async generators -<br>
precisely because it was proving impossible to gain consensus on how<br>
to handle those cases. We can't expect PEP 567 to satisfy an unstated<br>
requirement that "it must be possible to extend it to provide full PEP<br>
550 functionality later". Is there a reason within the stated design<br>
goals of PEP 567 why Victor's implementation is incorrect? In PEP 567<br>
the *only* point of the Context is to provide a means of implementing<br>
the consideration described in the Introduction: "The notion of<br>
"current value" deserves special consideration: different asynchronous<br>
tasks that exist and execute concurrently may have different values<br>
for the same key".<br>
<br>
Having said this, I don't really see the need for Victor's<br>
re-implementation. The wording of the PEP needs some work, as it mixes<br>
implementation details with design in a way that makes it confusing,<br>
but unlike Victor I don't see this as unfixable. I'd be perfectly<br>
happy with Yury's implementation, but with better documentation that<br>
focuses on the use of the feature and separates the implementation<br>
aspects out clearly. This seems to be a general problem with async -<br>
usage-focused documentation that ignores implementation details is<br>
very hard to find, and the experts seem to struggle to keep<br>
implementation details "behind the scenes". IMO, we need to do more to<br>
help push for user-friendly documentation, which is why I'd rather<br>
concentrate on helping Yury document context variables in a way that<br>
doesn't expose implementation details, rather than trying to<br>
understand and critique those implementation details (people like<br>
Victor are far better at doing that than I am :-))<br>
<span class=""><br>
> Maybe it would help a little to rename get_context() to something like<br>
> snapshot_context()?<br>
<br>
</span>Maybe? But at the moment, the PEP says "the context is immutable" so<br>
it shouldn't make a difference (and in fact get_ makes more sense than<br>
snapshot_ as long as the context is immutable). I'd prefer we work on<br>
clarifying whether (conceptually - not in terms of implementation!)<br>
the context should be described as immutable, and once we understand<br>
that I suspect answers to questions like this will be obvious.<span class="HOEnZb"></span><br></blockquote></div><br clear="all"></div><div class="gmail_extra">In the other thread I think we've clarified what the (im)mutability status of Context is. I don't think we need Victor's implementation either and I agree with Paul that the PEP just needs a better specification / description of the API it offers. Also let's not tweak the name of the function that retrieves a copy of the current context just yet. The PEP has it as copy_context(). Let's keep that.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>