[Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

[Yury Selivanov]

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,
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