Also, IMO this is all the interface we should need to explain to users (even framework authors): https://github.com/gvanrossum/pep550/blob/master/simpler.py
On Tue, Oct 17, 2017 at 11:25 AM, Guido van Rossum <gu...@python.org> wrote: > 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) > -- --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
