←back to thread

A “frozen” dictionary for Python

(lwn.net)
191 points jwilk | 1 comments | 11 Dec 25 09:51 UTC | HN request time: 0.203s | source
Show context
sundarurfriend ◴[11 Dec 25 12:13 UTC] No.46230418[source]▶
Can someone ELI5 the core difference between this and named tuples, for someone who is not deep into Python? ChatGPT's answer boiled down to: unordered (this) vs ordered (NTs), "arbitrary keys, decided at runtime" vs "fixed set of fields decided at definition time" (can't an NT's keys also be interpolated from runtime values?), and a different API (`.keys()`, `.items()`), etc (I'm just giving this as context btw, no idea if there's inaccuracies in these).

So could this also have been approached from the other side, as in making unordered NamedTuples with support for the Mapping API? The line between dictionaries and named tuples and structs (across various languages) has always seemed a bit blurry to me, so I'm trying to get a better picture of it all through this.

replies(5): >>46230459 #>>46230674 #>>46230747 #>>46230783 #>>46237202 #
1. quietbritishjim ◴[11 Dec 25 12:49 UTC] No.46230747[source]▶
> arbitrary keys, decided at runtime" vs "fixed set of fields decided at definition time" (can't an NT's keys also be interpolated from runtime values?)

If you want to create a named tuple with arbitrary field names at runtime then you need to create a new named tuple type before you create the instance. That is possible, since Python is a very dynamic language, but it's not particularly efficient and, more importantly, just feels a bit wrong. And are you going to somehow cache the types and reuse them if the field names match? It's all a bit of a mess compared to just passing the entries to the frozendict type.