On Mon, Aug 21, 2017 at 10:09 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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). > I think I like ImplicitContext. Maybe we can go with this as a working title at least. I think we should also rethink the form the key framework-facing APIs will take, and how they are presented in the PEP -- I am now leaning towards explaining this from the start as an immutable linked list of immutable mappings, where the OS-thread state gets updated to a new linked list when it is changed (either by ContextKey.set or by the various stack manipulations). I think this falls under several Zen-of-Python points: EIBTI, and "If the implementation is easy to explain, it may be a good idea." -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
_______________________________________________ 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
