<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-1003859177773148303gmail-">On Mon, Sep 4, 2017 at 2:50 PM, Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>> wrote:<br>
</span><span class="m_-1003859177773148303gmail-">> Hi all,<br>
><br>
> as promised, here is a draft PEP for context variable semantics and<br>
> implementation. Apologies for the slight delay; I had a not-so-minor<br>
> autosave accident and had to retype the majority of this first draft.<br>
><br>
> During the past years, there has been growing interest in something like<br>
> task-local storage or async-local storage. This PEP proposes an alternative<br>
> approach to solving the problems that are typically stated as motivation for<br>
> such concepts.<br>
<br>
</span>From a quick skim, my impression is:<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​Well, I'm happy to hear that a quick skim can already give you an impression ;).​ But let's see how correct...</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
All the high-level semantics you suggest make sense... in fact, AFAICT<br>
they're exactly the same semantics we've been using as a litmus test<br>
for PEP 550. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Well, if "exactly the same semantics" is even nearly true, you are only testing a small subset of PEP 550 which resembles a subset of this proposal.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think PEP 550 is sufficient to allow implementing all<br>
your proposed APIs (and that if it isn't, that's a bug in PEP 550).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">That's not true either. The LocalContext-based semantics introduces scope barriers that affect *all* variables. You might get close by putting just one variable in a LogicalContext and then nest them, but PEP 550 does not allow this in all cases. With the addition of PEP 521 and some trickery, it might. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">See also this section in PEP 550, where one of the related issues is described:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://www.python.org/dev/peps/pep-0550/#should-yield-from-leak-context-changes" target="_blank">https://www.python.org/dev/<wbr>peps/pep-0550/#should-yield-<wbr>from-leak-context-changes</a></font><br></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
OTOH, your proposal doesn't provide any way to implement functions<br>
like decimal.setcontext or numpy.seterr, except by pushing a new state<br>
and never popping it, which leaks memory and permanently increases the<br>
N in the O(N) lookups.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​Well, there are different approaches for this. Let's take the example of numpy.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">import numpy as np</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I believe the relevant functions are </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">np.seterr -- set a new state (and return the old one)</div><div class="gmail_default" style="font-family:monospace,monospace">np.geterr -- get the current state</div><div class="gmail_default" style="font-family:monospace,monospace">np.errstate -- gives you a context manager to do handle </div><div class="gmail_default" style="font-family:monospace,monospace">     </div><div class="gmail_default" style="font-family:monospace,monospace">(Well, errstate sets more state than np.seterr, but that's irrelevant here). <br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">First of all, the np.seterr API is something that I want to discourage in this proposal, because if the state is not reset back to what it was, a completely different piece of code may be affected.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">BUT</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">To preserve the current semantics of these functions in non-async code, you could do this:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">- numpy reimplements the errstate context manager using contextvars based on this proposal.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">- geterr gets the state using contextvars</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">- seterr gets the state using contextvars and mutates it the way it wants</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">(If contextvars is not available, it uses the old way)<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Also, the idea is to also provide frameworks the means for implementing concurrency-local storage, if that is what people really want, although I'm not sure it is.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"> </span><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I didn't see any direct comparison with PEP 550 in your text (maybe I<br>
missed it). Why do you think this approach would be better than what's<br>
in PEP 550?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">It was not my intention to leave out the comparison altogether, but I did avoid the comparisons in some cases in this first draft, because thinking about PEP 550 concepts while trying to understand this proposal might give you the wrong idea.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">One of the benefits of this proposal is simplicity, and I'm guessing performance as well, but that would need evidence.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div></div><div><br></div></div><br clear="all"><div><br></div>-- <br><div class="m_-1003859177773148303gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>