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

[Eric Snow]

On Thu, Aug 24, 2017 at 7: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!).

The precedent (and perhaps inspiration) here lies in decimal.context
[1] and ssl.SSLContext [2].  email.Policy [3] qualifies in spirit, as
does the import state [4]. Each encapsulates the state of some
subsystem.  They can be enabled in the current thread via a context
manager.  (Well, only the first two, but the latter two are strong
candidates.)  They are each specific to a *logical* execution context.
Most notably, each is implicit global state in the current thread of
execution.

PEP 550, if I've understood right, is all about supporting these
contexts in other logical threads of execution than just Python/OS
threads (e.g. async, generators).  Given all that, "context" is an
understandable name to use here.

Personally, I'm still on the fence on if "context" fits in the name.
:)  None of the proposed names have felt quite right thus far, which
is probably why we're still talking about it! :)

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

"scope" fits because it's all about chained lookup in implicit
namespaces.  However, to me the focus of PEP 550 is on the context
(encapsulated state) more than the chaining.

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

+1

-eric

[1] https://docs.python.org/3/library/ssl.html#ssl.SSLContext
[2] https://docs.python.org/3/library/decimal.html#context-objects
[3] https://docs.python.org/3/library/email.policy.html
[4] https://www.python.org/dev/peps/pep-0406/