[Python-Dev] Timeout for PEP 550 / Execution Context discussion
Guido van Rossum
guido at python.org
Tue Oct 17 14:25:37 EDT 2017
On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov <yselivanov.ml at gmail.com>
> On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The reason I say that is because one of the biggest future-proofing
> > when it comes to exposing a mapping as the lowest API layer is that it
> > 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
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev