On Tue, Jan 9, 2018 at 2:59 AM, Yury Selivanov <yseliva...@gmail.com> wrote: > > >> On Jan 9, 2018, at 11:18 AM, Nathaniel Smith <n...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
