On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw <ba...@python.org> wrote: > Guido van Rossum wrote: >> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> I worry that that's going to lead more people astray thinking this has >> something to do with contextlib, which it really doesn't (it's much more >> closely related to threading.local()). > > This is my problem with using "Context" for this PEP. Although I can't > keep up with all names being thrown around, it seems to me that in > Python we already have a well-established meaning for "contexts" -- > context managers, and the protocols they implement as they participate > in `with` statements. We have contextlib which reinforces this. What's > being proposed in PEP 550 is so far removed from this concept that I > think it's just going to cause confusion (well, it does in me anyway!).
Although nobody refers to context managers as "context", they are always called with on of the following: "context manager", "CM", "context manager protocol". PEP 550 just introduces a concept of "context", that "context managers" will be able to manage. > > To me, the functionality proposed in PEP 550 feels more like a "scope" > than a "context". Unlike a lexical scope, it can't be inferred from the > layout of the source code. It's more of a dynamic "execution scope" and > the stacking of "local execution scopes" reinforces that for me. You > use a key to find a value in the current execution scope, and it chains > up until the key is found or you've reached the top of the local > execution (defined as the thread start, etc.). Yes, what PEP 550 proposes can be seen as a new scoping mechanism. But calling it a "scope" or "dynamic scope" would be a mistake (IMHO), as Python scoping is already a complex topic (with locals, nonlocals, globals, etc). Contrary to scoping, the programmer is much less likely to deal with Execution Context. How often do we use "threading.local()"? > One other suggestion: maybe we shouldn't put these new functions in sys, > but instead put them in their own module? It feels analogous to the gc > module; all those functions could have gone in sys since they query and > effect the Python runtime system, but it makes more sense (and improves > the naming) by putting them in their own module. It also segregates the > functionality so that sys doesn't become a catchall that overloads you > when you're reading through the sys module documentation. I'm myself not a big fan of jamming all PEP 550 APIs into the sys module. We just need to come up with a good name. Yury _______________________________________________ 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
