(original) (raw)

On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:

On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan <ncoghlan@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)