On Aug 25, 2017, at 10:18, Yury Selivanov <yselivanov...@gmail.com> wrote: > > I has a similar idea when I discovered that PEP 550 can't be used > directly to fix sys.std* streams redirection. Another idea: > > 1. We alter PyModule to make it possible to add properties (descriptor > protocol, or we implement custom __getattr__). I think we can make it > so that only sys module would be able to actually use it, so it's not > going to be a new feature -- just a hack for CPython. > > 2. We make sys.std* attributes properties, with getters and setters. > > 3. sys.std* setters will: issue a DeprecationWarning; set whatever the > user wants to set in a global variable + set a flag (let's call it > "sys.__stdout_global_modified") that sys.std* were modified. > > 4. sys.std* getters will use PEP 550 to lookup when > __stdout_global_modified is false. If it's true -- we fallback to > globals. > > 5. We deprecate the current API and add new APIs for the redirection > system that uses PEP 550 explicitly. > > 6. In Python 4 we remove the old sys.std* API. > > Thit is still *very* fragile: any code that writes to sys.stdout > breaks all assumptions. But it offers a way to raise a warning when > old-API is being used - something that we'll probably need if we add > new APIs to fix this problem.
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.
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.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
