[Python-Dev] PEP 567 v2 (original) (raw)

Yury Selivanov yselivanov at gmail.com
Tue Jan 9 05:59:57 EST 2018

On Jan 9, 2018, at 11:18 AM, Nathaniel Smith <njs at pobox.com> wrote:

On Thu, Jan 4, 2018 at 9:42 PM, Guido van Rossum <guido at python.org> wrote: On Thu, Jan 4, 2018 at 7:58 PM, Nathaniel Smith <njs at pobox.com> wrote: This does make me think that I should write up a short PEP for extending PEP 567 to add context lookup, PEP 550 style: it can start out in Status: deferred and then we can debate it properly before 3.8, but at least having the roadmap written down now would make it easier to catch these details. (And it might also help address Paul's reasonable complaint about "unstated requirements".)

Anything that will help us kill a 550-pound gorilla sounds good to me. :-) It might indeed be pretty short if we follow the lead of ChainMap (even using a different API than MutableMapping to mutate it). Maybe copycontext() would map to newchild()? Using ChainMap as a model we might even avoid the confusion between Lo[gi]calContext and ExecutionContext which was the nail in PEP 550's coffin. The LC associated with a generator in PEP 550 would be akin to a loose dict which can be pushed on top of a ChainMap using cm = cm.newchild(). (Always taking for granted that instead of an actual dict we'd use some specialized mutable object implementing the Mapping protocol and a custom mutation protocol so it can maintain ContextVar cache consistency.) The approach I took in PEP 568 is even simpler, I think. The PEP is a few pages long because I wanted to be exhaustive to make sure we weren't missing any details, but the tl;dr is: The ChainMap lives entirely inside the threadstate, so there's no need to create a LC/EC distinction -- users just see Contexts, or there's the one stack introspection API, getcontextstack(), which returns a List[Context]. Instead of messing with newchild, copycontext is just Context(dict(chainmap)) -- i.e., it creates a flattened copy of the current mapping. (If we used newchild, then we'd have to have a way to return a ChainMap, reintroducing the LC/EC mess.

This sounds reasonable. Although keep in mind that merging hamt is still an expensive operation, so flattening shouldn't always be performed (this is covered in 550).

I also wouldn't call LC/EC a "mess". Your pep just names things differently, but otherwise is entirely built on concepts and ideas introduced in pep 550.

Yury

More information about the Python-Dev mailing list