PEP 603: Adding a frozenmap type to collections

Having finally read through this thread[1], I thought I’d at least chime in with my own thoughts/wishes

Overall, my own ideal scenario if I had a magic wand and decision rights would be that both a PEP 416 style frozendict was added as a builtin and a PEP 603 style HAMT based immutable not-a-dict mapping was added to collections.

They both serve different purposes and would both be useful in different scenarios, and I imagine having just the HAMT based PEP 603 frozenmap would lead to inevitable confusion (seen a couple of times throughout this thread) that it works just like dict when that is not at all what is optimized for.

Alyssa’s suggestion of the name SnapshotMap is my personal favorite suggestion I’ve seen for the bikeshed-naming question and would fit in well alongside ChainMap in the collections module.

In my mind, it immediately evokes what the mapping is good at, i.e. creating space- and time-efficient snapshots of the mapping at different states. The fact that it’s a mapping that’s frozen/immutable isn’t the actual useful, interesting part, it’s that you can easily create modified versions and then rollback those changes to a previous version when needed.

The most compelling argument I’ve seen for it being in the standard library is that the implementation already is, so why not[2] give it a public API and let everyone benefit from the great work that was done in implementing contextvars.

Similarly, the most compelling argument I’ve seen for adding a builtin frozendict is that it feels like the odd one out of the builtin collections, with

  • list: tuple
  • set: frozenset
  • dict: ???

Ideally it could reuse all of the implementation and optimizations that have gone into making dict efficient, keep all the same semantics as dict (e.g. O(1) lookup time, remembering insertion order, equality based on unordered keys and values), but just truly forbid anything that mutates it and add hashing support similar to how tuples work (i.e. hashable if all the values are hashable, raising a TypeError otherwise), then it seems like it would be a useful addition in some cases.

I personally don’t use frozensets very often, but there have been a couple of times where it’s fit a need perfectly and I’ve been very happy to have it, and I imagine that frozendicts would end up the the same


  1. And hopefully not being too annoying by adding on again to an old and very long thread ↩︎

  2. I know that is actually minimizing the additional maintenance and backwards-compatibility concerns of making something public, but I’ve got the magic wand to get exactly what I personally want ↩︎

7 Likes