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

[Barry Warsaw]

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!).

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.).

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.

Cheers,
-Barry