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

Nathaniel Smith njs at pobox.com
Wed Jan 10 18:52:21 EST 2018

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

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

More information about the Python-Dev mailing list