A “frozen” dictionary for Python

Typing and inference discussions

• Several comments want TypeScript-style inference: a frozendict literal should auto-infer a precise TypedDict type with Literal keys/values, i.e. “const dict” semantics purely at type-check time.
• Others note PEPs for inline TypedDict already exist, and argue the real missing piece is structural typing for dicts (protocol-like) rather than relying on nominal TypedDict classes.
• Some point out that current type checkers don’t infer TypedDicts automatically, and this feature doesn’t actually require frozendict at runtime.

Existing tools vs a builtin

• Python already has MappingProxyType, which exposes a read-only view, but it doesn’t guarantee the underlying dict is not mutated elsewhere.
• Multiple third‑party solutions are cited: pyrsistent (persistent maps/vectors), immutabledict, SQLAlchemy’s own frozendict, boltons.FrozenDict, JAX/Flax’s FrozenDict, etc.
• One line of argument: the existence and wide use of these libraries shows a real need; another: the rarity of MappingProxyType use suggests demand is low.

Immutability depth, concurrency, and correctness

• Pro‑frozendict comments emphasize: easier reasoning (“this mapping will never change”), safer sharing between threads/tasks, and better guarantees for cached results and APIs.
• Critics note immutability is shallow: values can still mutate, so it’s not full thread safety or full functional-style immutability.
• Some see it as a “half solution” compared to persistent structures (HAMT, pyrsistent), which support efficient copy-on-write and structural sharing.

Performance and implementation ideas

• Discussion on whether dict -> frozendict can be optimized to O(1) when the dict has a single refcount, but this is complicated by name shadowing and current PEP explicitly specifying an O(n) copy.
• Others mention potential JIT optimizations and contrast with functional implementations that use trees and path-copying.

Relationship to other Python types

• Comparisons with namedtuple/dataclasses: those work when keys/fields are known at definition time; frozendict suits dynamic key sets or lookup tables.
• Several people highlight that dict keys must be hashable, and the lack of hashable dicts today (forcing tuple-of-tuples hacks) is a concrete pain point.
• Side debate on ordered dicts and whether sets should or shouldn’t have stable order, plus regret/approval about dict insertion-order becoming language-guaranteed.

Rationale and skepticism

• Supporters cite concurrency, safer APIs, and hashable mappings as strong reasons for a builtin.
• Skeptics argue the benefit over tuples/frozenset/custom wrappers is marginal, worry about encouraging heavy copying instead of true persistent structures, and question whether this belongs in the core language at all.