[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>
wrote:

> 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
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171017/85b7a7eb/attachment.html>


More information about the Python-Dev mailing list