[Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)
yselivanov.ml at gmail.com
Thu Aug 24 10:23:23 EDT 2017
On Thu, Aug 24, 2017 at 9:52 AM, Barry Warsaw <barry at python.org> wrote:
> Guido van Rossum wrote:
>> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith <njs at 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,
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.
More information about the Python-Dev