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

71–80 of 172 posts

Re: A “frozen” dictionary for Python

#71

Post by kccqzy »

pansa2 wrote: post #50
zahlman wrote: post #39

Earlier quoted context omitted.

> 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…

> 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…

Yes you could. Other languages do. See NSMutableSet and NSSet in Objective-C.

Re: A “frozen” dictionary for Python

#72

Post by mrweasel »

cpburns2009 wrote: post #52
sltkr wrote: post #27

Earlier quoted context omitted.

So are dictionary keys, but Python decided to make them insertion ordered (after having them be unordered just like set elements for decades). There is no fundamental reason sets couldn't have a defined order. That's what languages like JavaScript have done too.

Python's decision to make dict keys ordered in the spec was a mistake. It may be the best implementation so far, but it eliminates potential improvements in the future.

Agreed. The only reason to make them sorted is because people would wrongly assume that they where. You can argue that a programming language should not have unexpected behaviors, and apparently unsorted dictionary keys where a surprise to many, on the other hand I feel like it's a failure of education.

The problem was that assuming that keys would be sorted was frequently true, but not guaranteed. An alternative solution would have been to randomize them more, but that would probably break a lot of old code. Sorting the keys makes no difference if you don't expect them to be, but it will now be a greater surprise if you switch language.

Re: A “frozen” dictionary for Python

#73

Post by ndr »

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

Immutability it's a joy to work with. Ask anyone who's worked with Clojure's dicts.

Re: A “frozen” dictionary for Python

#74

Post by clickety_clack »

Strilanc wrote: post #67

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. Curr…

Maybe you should take a look at pyrsistent. That allows you to make frozen “maps”. You can “evolve” them into new versions of the objects and it keeps the references to the unchanged keys and values under the hood so it’s fast and memory efficient.

Re: A “frozen” dictionary for Python

#75

Post by perrygeo »

Python discovers immutable data, and gets it wrong. Frozendict is a blunt instrument - instead of a mutable free-for-all, it just locks the data for the entire lifecycle. Brace for the wave of code littered with deep copies, proudly proclaiming how functional it all is.

If you want real immutable data structures, not a cheap imitation, check out pyrsistent.

Re: A “frozen” dictionary for Python

#76

Post by ndr »

Someone wrote: post #69
sesm wrote: post #61

Earlier quoted context omitted.

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.

HAMT weren't immutable/persistent until Clojure though: https://en.wikipedia.org/wiki/Persistent_data_structure#Pers...

Still well before the talk.

Re: A “frozen” dictionary for Python

#77

Post by xamuel »

kzrdude wrote: post #55
xamuel wrote: post #46

This subject always seems to get bogged down in discussions about ordered vs. unordered keys, which to me seems totally irrelevant. No-one seems to mention the glaring shortcoming which is that, since dictionary keys are required to be hashable, Python has the bizarre situation where dicts cannot be dict keys, as in... {{'foo': 'bar'}: 1, {3:4, 5:6}: 7} ...and there is no reasonable builtin way to get around this! Yo…

Turning a dictionary into a tuple of tuples `((k1, v1), (k2, v2), ...)`; isn't that a reasonable way? If you want to have hash map keys, you need to think about how to hash them and how to compare for equality, it's just that. There will be complications to that such as floats, which have a tricky notion of equality, or in Python mutable collections which don't want to be hashable.

That argument would apply to sets too, and yet frozenset is builtin.

Re: A “frozen” dictionary for Python

#79

Post by shadowgovt »

Regarding the spooky-action-at-a-distance concerns of a `.freeze()` method on dict:

`.freeze()` should probably just return a frozendict instead of in-place mutating the dict, and they should be separate types. Under the hood, you'll have to build the hashtable anyway to make the frozendict; as long as you're doing that work, you may as well build an object to contain the hashtable and just have that object be separate from the dict that birthed it.

The values referenced by both the original dict and the frozendict can be the same values; no need to clone them.

Re: A “frozen” dictionary for Python

#80

Post by shadowgovt »

perrygeo wrote: post #75

Python discovers immutable data, and gets it wrong. Frozendict is a blunt instrument - instead of a mutable free-for-all, it just locks the data for the entire lifecycle. Brace for the wave of code littered with deep copies, proudly proclaiming how functional it all is. If you want real immutable data structures, not a cheap imitation, check out pyrsistent.

If your dicts are frozen, you shouldn't need to deep-copy. The point of immutability is that if you want a new frozendict based on another one, you just rebuild the indirection data structure up top and leave the values it references alone.
Post reply on HN