On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum <guido at python.org> wrote: > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov <yselivanov.ml at gmail.com> [..] >> 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.) I don't really care about the implementation work that has already been done, it's OK if I write it from scratch again. I actually like what you did in https://github.com/gvanrossum/pep550/blob/master/simpler.py, it seems reasonable. The only thing that I'd change is to remove "set_ctx" from the public API and add "Context.run(callable)". This makes the API more flexible to potential future changes and amendments. > In short, I really don't think there's a need for context variables to be > faster than instance variables. Well, even our current idea about the API, doesn't really prohibit us from adding a cache to ContextVar.get(). That would be an implementation detail, right? Same as our latest optimization for creating bound methods (CALL_METHOD & LOAD_METHOD opcodes), which avoids creating bound method instances when it's OK not to. Yury
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4