[Python-Dev] PEP 567 v2

[Yury Selivanov]

> 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
>> copy_context() would map to new_child()? 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.new_child(<dict>). (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, get_context_stack(), which returns a List[Context].
> Instead of messing with new_child, copy_context is just
> Context(dict(chain_map)) -- i.e., it creates a flattened copy of the
> current mapping. (If we used new_child, 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