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

[Eric Snow]

On Fri, Aug 25, 2017 at 9:10 AM, Barry Warsaw <barry at python.org> wrote:
> It’s ideas like this that do make me think of scopes when talking about global state and execution contexts.  I understand that the current PEP 550 invokes an explicit separate namespace,

Right.  The observation that PEP 550 proposes a separate stack of
scopes from the lexical scope is an important one.

> but thinking bigger, if the usual patterns of just writing to sys.std{out,err}  still worked and in the presence of single “threaded” execution it just did the normal thing, but in the presence of threads, async, etc. it *also* did the right thing, then code wouldn’t need to change just because you started to adopt async.  That implies some scoping rules to make “sys.stdout” refer to the local execution’s sys.stdout if it were set, and the global sys.stdout if it were not.

Yeah, at the bottom of the PEP 550 stack there'd need to be a proxy to
the relevant global state.  While working on the successor to PEP 406
(import state), I realized I'd need something like this.

>
> This would of course be a much deeper change to Python, with lots of tricky semantics and corner cases to get right.  But it might be worth it to provide an execution model and an  API that would be harder to get wrong because Python just Does the Right Thing.  It’s difficult because you also have to be able to reason about what’s going on, and it’ll be imperative to be able to debug and examine the state of your execution when things go unexpected.  That’s always harder when mixing dynamic scope with lexical scope, which I think is what PEP 550 is ultimately getting at.

+1  Thankfully, PEP 550 is targeted more at a subset of library
authors than at the general population.

-eric