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

[Barry Warsaw]

On Aug 24, 2017, at 10:23, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> 
> 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()”?

Yes, but in conversations about Python, the term “context” (in the context of context managers) comes up way more often than the term “scope”.  I actually think Python’s scoping rules are fairly easy to grasp, as there aren’t that many levels or ways to access them, and the natural, common interactions are basically implicit when thinking about the code you’re writing.

So while “context”, “environment”, and “scope” are certainly overloaded terms in Python, the first two have very specific existing, commonplace constructs within Python, and “scope” is both the least overloaded of the three and most closely matches what is actually going on.

A different tack would more closely align with PEP 550’s heritage in thread-local storage, calling these things “execution storage”.  I think I read Guido suggest elsewhere using a namespace here so that in common code you’d only have to change the “threading.local()” call to migrate to PEP 550.  It might be neat if you could do something like:

import execution
els = execution.local()
els.x = 1

By calling it “execution local storage” you’re also providing a nicer cognitive bridge from “thread local storage”, a concept anybody diving into this stuff will already understand pretty innately.  No need to get fancy, we just think “Oh, I know what thread local storage is, and this seems related but slightly different, so now I basically understand what execution local storage is”.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170824/bd72c287/attachment.sig>