On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > The reason I say that is because one of the biggest future-proofing > concerns > > when it comes to exposing a mapping as the lowest API layer is that it > makes > > the following code pattern possible: > > > > ec = get_execution_context() > > # Change to a different execution context > > ec[key] = new_value > > I *really* don't want to make ECs behave like 'locals()'. That will > make everything way more complicated. > 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). > My way of thinking about this: "get_execution_context()" returns you a > shallow copy of the current EC (at least conceptually). So making any > modifications on it won't affect the current environment. The only > way to actually apply the modified EC object to the environment will > be its 'run(callable)' method. > 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.) In short, I really don't think there's a need for context variables to be faster than instance variables. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
