[Python-Dev] PEP 550 v3 (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Aug 22 01:09:05 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 550 v3
- Next message (by thread): [Python-Dev] PEP 550 v3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 22 August 2017 at 09:39, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
Ethan Furman wrote:
So I like ExecutionContext for the stack of WhateverWeCallTheOtherContext contexts. But what do we call it? How about ExecutionContextFrame, by analogy with stack/stack frame.
My latest suggestion to Yury was to see how the PEP reads with it called ImplicitContext, such that:
- the active execution context is a stack of implicit contexts
- ContextKey.set() updates the innermost implicit context
- Contextkey.get() reads the whole stack of active implicit contexts
- by default, generators (both sync and async) would have their own implicit context, but you could make them use the context of method callers by doing "gen.implicit_context = None"
- by default, coroutines would use their method caller's context, but async frameworks would make sure to give top-level tasks their own independent contexts
That proposal came from an initial attempt at redrafting the Abstract and Rationale sections, where it turns out that one of the things the current version of the PEP is somewhat taking for granted is that the reader already has a particular understanding of the difference between explicit state management (i.e. passing things around as function arguments and instance attributes) and implicit state management (i.e. relying on process globals and thread locals).
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] PEP 550 v3
- Next message (by thread): [Python-Dev] PEP 550 v3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]