[Python-Dev] PEP 567 v2

[Nathaniel Smith]

On Tue, Jan 9, 2018 at 2:59 AM, Yury Selivanov <yselivanov at gmail.com> wrote:
>
>
>> On Jan 9, 2018, at 11:18 AM, Nathaniel Smith <njs at pobox.com> wrote:
>> 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).

Right, the PEP mostly focuses on the semantics rather than the
implementation and this is an implementation detail (the user can't
tell whether a Context internally holds a stack of HAMTs or just one).
But there is a note that we might choose to perform the actual
flattening lazily if it turns out to be worthwhile.

> 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.

Sorry for phrasing it like that -- I just meant that at the API level,
the LC/EC split caused a lot of confusion (and apparently this was
it's "nail in the coffin"!). In the PEP 567/568 version, the
underlying concepts are the same, but the API ends up being simpler.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org