[Python-Dev] PEP 550 v3 (original) (raw)

Guido van Rossum guido at python.org
Tue Aug 22 11:34:55 EDT 2017

On Mon, Aug 21, 2017 at 10:09 PM, Nick Coghlan <ncoghlan at 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.implicitcontext = 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>) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170822/38ecb7d7/attachment.html>

More information about the Python-Dev mailing list