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

Nick Coghlan ncoghlan at gmail.com
Fri Aug 25 09:48:25 EDT 2017

On 25 August 2017 at 23:36, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

On Fri, Aug 25, 2017 at 9:23 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: [..]

And while PEP 550 doesn't handle the stream redirection case natively (since it doesn't allow for suspend/resume callbacks the way PEP 525 does), it at least allows for the development of a context-aware output stream wrapper API where: PEP 525 can't handle streams redirection -- it can do it only for single-threaded programs.

Good point, whereas the hypothetical context-aware wrapper I proposed would be both thread-safe (since the process global would be changed once before the program went multi-threaded and then left alone) and potentially lower overhead (one context local lookup per stream attribute access, rather than a global state change every time a frame was suspended or resumed with a stream redirected)

sys.stdout/stderr/stdin are global variables, that's how the API is specified. API users assume that the change is process-wide.

Yeah, I wasn't suggesting any implicit changes to the way those work.

However, it does occur to me that if we did add a new "contextlocals" API, then:

  1. It could offer context-aware wrappers for stdin/stdout/stderr
  2. If could offer context-aware alternatives to the stream redirection context managers in contextlib

That approach would work even better than replacing sys.stdin/out/err themselves with wrappers since the wrappers wouldn't be vulnerable to being overwritten by other code that mutated the sys module.

Anyway, that's not a serious proposal right now, but I do think it's decent validation of the power and flexibility of the proposed implicit state management model.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list