<div dir="ltr">Also, IMO this is all the interface we should need to explain to users (even framework authors):<br><a href="https://github.com/gvanrossum/pep550/blob/master/simpler.py">https://github.com/gvanrossum/pep550/blob/master/simpler.py</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 17, 2017 at 11:25 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div class="m_-6708443171784689792HOEnZb"><div class="m_-6708443171784689792h5">On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<span></span><br><span></span></div></div></span><span class=""><span>
> The reason I say that is because one of the biggest future-proofing concerns<br>
> when it comes to exposing a mapping as the lowest API layer is that it makes<br>
> the following code pattern possible:<br>
><br>
>     ec = get_execution_context()<br>
>     # Change to a different execution context<br>
>     ec[key] = new_value<br>
<br>
</span>I *really* don't want to make ECs behave like 'locals()'.  That will<br>
make everything way more complicated.<br></span></blockquote><div><br></div><div>At least some of the problems with locals() have more to do with the legacy of that function than with inherent difficulties. And local variables might be optimized by a JIT in a way that context vars never will be (or at least if we ever get to that point we will be able to redesign the API first).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My way of thinking about this: "get_execution_context()" returns you a<br>
shallow copy of the current EC (at least conceptually).  So making any<br>
modifications on it won't affect the current environment.  The only<br>
way to actually apply the modified EC object to the environment will<br>
be its 'run(callable)' method.<span class="m_-6708443171784689792HOEnZb"><font color="#888888"><br>
</font></span></blockquote></span></div><br></div><div class="gmail_extra">I understand that you don't want to throw away the implementation work you've already done. But I find that the abstractions you've introduced are getting in the way of helping people understand what they can do with context variables, and I really want to go back to a model that is *much* closer to understanding how instance variables are just self.__dict__. (Even though there are possible complications due to __slots__ and @property.)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">In short, I really don't think there's a need for context variables to be faster than instance variables.<br clear="all"></div><span class=""><div class="gmail_extra"><br>-- <br><div class="m_-6708443171784689792gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></span></div>
</blockquote></div><br><br clear="all"><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>