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

[Yury Selivanov]

On Fri, Aug 25, 2017 at 11: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, 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.

The problem here is exactly the "usual patterns of just writing to
sys.std{out,err}". The usual pattern assumes that it's a global
variable, and there are no ways of getting around this. None. There
are many applications out there that are already written with the
assumption that setting sys.stdout changes it for all threads, which
means that we cannot change this already established semantics.

The sys.std* API just needs to be slowly deprecated and replaced with
a new API that uses context managers and does things differently under
the hood, *if* and only if, we all agree that we even need to solve
this problem.

This is a completely separate problem from the one that PEP 550
solves, which is providing a better TLS that is aware of generators
and async code.

Yury