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