On Fri, Aug 25, 2017 at 9:10 AM, Barry Warsaw <ba...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
