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

[Barry Warsaw]

On Aug 25, 2017, at 10:18, Yury Selivanov <yselivanov.ml at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170825/06c36d1d/attachment.sig>