Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A “frozen” dictionary for Python

lwn.net

Post reply on HN
Print view View original

61–70 of 172 posts

Re: A “frozen” dictionary for Python

#61

Post by sesm »

aewens wrote: post #51
mvanbaak wrote: post #32

Earlier quoted context omitted.

This was 19 (almost) 20 years ago. As stated in the lwn.net article, a lot of concurrency has been added to python, and it might now be time for something like a frozendict. Things that were not useful in 2006 might be totally useful in 2026 ;P Still, like you, I'm curious wether he has anything to say about it.

I think Raymond Hettinger is called out specially here because he did a well known talk called [Modern Dictionaries]( https://youtu.be/p33CVV29OG8 ) where around 32:00 to 35:00 in he makes the quip about how younger developers think they need new data structures to handle new problems, but eventually just end up recreating / rediscovering solutions from the 1960s. “What has been is what will be, and what has been don…

Since that time HAMT was invented and successfully used in Scala and Clojure, so this talk didn't age well.

Re: A “frozen” dictionary for Python

#62

Post by zahlman »

jonathaneunice wrote: post #58
zahlman wrote: post #40

Earlier quoted context omitted.

> Also worth noting that understanding changes over time. Remember when GvR and the rest of the core developers argued adamantly against ordered dictionaries? Haha! Good times! The new implementation has saved space, but there are opportunities to save more space (specifically after deleting keys) that they've now denied themselves by offering the ordering guarantee.

Ordering, like stability in sorting, is an incredibly useful property. If it costs a little, then so be it. This is optimizing for the common case, where memory is generally plentiful and dicts grow more than they shrink. Python has so many memory inefficiencies that occasional tombstones in the dict internal structure is unlikely to be a major effect. If you're really concerned, do `d = dict(d)` after aggressive del…

> Ordering, like stability in sorting, is an incredibly useful property.

I can't say I've noticed any good reasons to rely on it. Didn't reach for `OrderedDict` often back in the day either. I've had more use for actual sorting than for preserving the insertion order.

Re: A “frozen” dictionary for Python

#63

Post by tremon »

chriswarbo wrote: post #57
pansa2 wrote: post #50

Earlier quoted context omitted.

> ImmutableFoo as a subclass of Foo is never going to work. And, indeed, `set` and `frozenset` don't have an inheritance relationship. Theoretically, could `set` be a subclass of `frozenset` (and `dict` of `frozendict`)? Do other languages take that approach? > linking [immutability] more explicitly to hashability AFAIK immutability and hashability are equivalent for the language's "core" types. Would it be possible…

> Theoretically, could `set` be a subclass of `frozenset` (and `dict` of `frozendict`)? At one extreme: sure, anything can be made a subclass of anything else, if we wanted to. At the other extreme: no, since Liskov substitution is an impossibly-high bar to reach; especially in a language that's as dynamic/loose as Python. For example, consider an expression like '"pop" in dir(mySet)'

> consider an expression like '"pop" in dir(mySet)'

  class frozenset:
    pass
  
  class set(frozenset):
    def pop(self, key):
      pass
I don't see why hasattr(mySet, 'pop') should be a problem here?

Re: A “frozen” dictionary for Python

#64

Post by dkarl »

pansa2 wrote: post #20

I wonder whether Raymond Hettinger has an opinion on this PEP. A long time ago, he wrote: "freezing dicts is a can of worms and not especially useful". https://mail.python.org/pipermail/python-dev/2006-February/0...

It's interesting that he concludes that freezing dicts is "not especially useful" after addressing only a single motivation: the use of a dictionary as a key.

He doesn't address the reason that most of us in 2025 immediately think of, which is that it's easier to reason about code if you know that certain values can't change after they're created.

What a change in culture over the last 20 years!

Re: A “frozen” dictionary for Python

#66

Post by TheFlyingFish »

guidopallemans wrote: post #56
aewens wrote: post #41

Earlier quoted context omitted.

You may be thinking of the `frozenset()` built in or the third party Python module [frozendict]( https://pypi.org/project/frozendict/ )? Personally, I’ve been using a wrapper around `collections.namedtuple` as an underlying data structure to create frozen dictionaries when I’ve needed something like that for a project.

When you are making str -> Any dictionaries it's quite likely you're better off with dataclasses or namedtuples anyway.

That works if you're dealing with a known set of keys (i.e. what most statically-typed languages would call a struct). It falls down if you need something where the keys are unknowable until runtime, like a lookup table.

I do like dataclasses, though. I find them sneaking into my code more and more as time goes on. Having a declared set of properties is really useful, and it doesn't hurt either that they're syntactically nicer to use.

Re: A “frozen” dictionary for Python

#67

Post by Strilanc »

This is a type that I would use a lot.

For example, I often write classes that do cacheable analysis that results in a dict (e.g. the class stores a list of tiles defined by points and users want a point-to-tiles mapping for convenience). It's worth caching those transformations, e.g. using @functools.cached_property, but this introduces a risk where any caller could ruin the returned cached value by editing it. Currently, I take the safety hit (cache a dict) instead of the performance hit (make a new copy for each caller). Caching a frozendict would be a better tradeoff.

Re: A “frozen” dictionary for Python

#69

Post by Someone »

sesm wrote: post #61
aewens wrote: post #51

Earlier quoted context omitted.

I think Raymond Hettinger is called out specially here because he did a well known talk called [Modern Dictionaries]( https://youtu.be/p33CVV29OG8 ) where around 32:00 to 35:00 in he makes the quip about how younger developers think they need new data structures to handle new problems, but eventually just end up recreating / rediscovering solutions from the 1960s. “What has been is what will be, and what has been don…

Since that time HAMT was invented and successfully used in Scala and Clojure, so this talk didn't age well.

Wikipedia (https://en.wikipedia.org/wiki/Hash_array_mapped_trie) links to the paper describing HAMT (https://infoscience.epfl.ch/server/api/core/bitstreams/f66a3...) and claims that is from 2000. That talk is from 2016.

Re: A “frozen” dictionary for Python

#70

Post by kccqzy »

zahlman wrote: post #39
pansa2 wrote: post #20

I wonder whether Raymond Hettinger has an opinion on this PEP. A long time ago, he wrote: "freezing dicts is a can of worms and not especially useful". https://mail.python.org/pipermail/python-dev/2006-February/0...

> Another PEP 351 world view is that tuples can serve as frozenlists; however, that view represents a Liskov violation (tuples don't support the same methods). This idea resurfaces and has be shot down again every few months. ... Well, yes; it doesn't support the methods for mutation . Thinking of ImmutableFoo as a subclass of Foo is never going to work. And, indeed, `set` and `frozenset` don't have an inheritance re…

Apple (or perhaps NeXT) has solved this problem already in Objective-C. Look at NSArray and NSMutableArray, or NSData and NSMutableData. It’s intuitive and Liskov-correct to make the mutable version a subclass of the immutable version. And it’s clearly wrong to have the subclass relationship the other way around.

Given how dynamic Python is, such a subclass relationship need not be evident at the C level. You can totally make one class whose implementation is independent of another class a subclass of the other, using PEP 3119. This gives implementations complete flexibility in how to implement the class while retaining the ontological subclass relationship.

Post reply on HN