Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171017/85b7a7eb/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<span class=""></span><br><span class=""></span></div></div><span class="">
> 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></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><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="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></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><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>
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