On 13 August 2017 at 11:27, Yury Selivanov <yselivanov...@gmail.com> wrote: > Yes, I considered this idea myself, but ultimately rejected it because: > > 1. Current solution makes it easy to introspect things. Get the > current EC and print it out. Although the context item idea could be > extended to `sys.create_context_item('description')` to allow that.
I think the TLS/TSS precedent means we should seriously consider the ContextItem + ContextStateToken approach for the core low level API. We also have a long history of pain and quirks arising from the locals() builtin being defined as returning a mapping even though function locals are managed as a linear array, so if we can avoid that for the execution context, it will likely be beneficial for both end users (due to less quirky runtime behaviour, especially across implementations) and language implementation developers (due to a reduced need to make something behave like an ordinary mapping when it really isn't). If we decide we want a separate context introspection API (akin to inspect.getcouroutinelocals() and inspect.getgeneratorlocals()), then an otherwise opaque ContextStateToken would be sufficient to enable that. Even if we don't need it for any other reason, having such an API available would be desirable for the regression test suite. For example, if context items are hashable, we could have the following arrangement: # Create new context items sys.create_context_item(name) # Opaque token for the current execution context sys.get_context_token() # Switch the current execution context to the given one sys.set_context(context_token) # Snapshot mapping context items to their values in given context sys.get_context_items(context_token) As Nathaniel suggestion, getting/setting/deleting individual items in the current context would be implemented as methods on the ContextItem objects, allowing the return value of "get_context_items" to be a plain dictionary, rather than a special type that directly supported updates to the underlying context. > 2. What if we want to pickle the EC? If all items in it are > pickleable, it's possible to dump the EC, send it over the network, > and re-use in some other process. It's not something I want to > consider in the PEP right now, but it's something that the current > design theoretically allows. AFAIU, `ci = sys.create_context_item()` > context item wouldn't be possible to pickle/unpickle correctly, no? As Nathaniel notes, cooperative partial pickling will be possible regardless of how the low level API works, and starting with a simpler low level API still doesn't rule out adding features like this at a later date. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/