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

11–20 of 172 posts

Re: A “frozen” dictionary for Python

#12

Post by sundarurfriend »

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.

Re: A “frozen” dictionary for Python

#13

Post by dmurray »

mrweasel wrote: post #10
codethief wrote: post #2

Next step: Auto-inferring the correct (most narrow) TypedDict type from a frozendict. (Think `const foo = { … } as const` in TypeScript.) I miss this TS feature in Python on the daily.

What would that do exactly? Auto-generate a TypedDict class? Bringing up TypedDict is sort of interesting, because it seems like a frozen dictionary could have been implemented by PEP 705, if typing.ReadOnly was enforced at runtime, and not just a hint to a static type checker.

Auto-generate a TypedDict type while type checking, while doing nothing at runtime.

I expect this is not a very big ask and the various typecheckers will have versions of this soon after release.

Re: A “frozen” dictionary for Python

#14

Post by grimgrin »

sundarurfriend wrote: post #12

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…

I think you could have asked this same comment w/o mentioning ChatGPT and you wouldn't have been downvoted to oblivion in 3 minutes

I don't see anything wrong with your asking to understand

Re: A “frozen” dictionary for Python

#16

Post by mrweasel »

dmurray wrote: post #13
mrweasel wrote: post #10

Earlier quoted context omitted.

What would that do exactly? Auto-generate a TypedDict class? Bringing up TypedDict is sort of interesting, because it seems like a frozen dictionary could have been implemented by PEP 705, if typing.ReadOnly was enforced at runtime, and not just a hint to a static type checker.

Auto-generate a TypedDict type while type checking, while doing nothing at runtime. I expect this is not a very big ask and the various typecheckers will have versions of this soon after release.

Okay so basically just "inline":

  class MyType(TypedDict):
    a: str
    b: int
or infer the type hint in:

  my_typed_dict: dict[str, int] = {"a": 5}
It should probably be something like:

  auto_typed: dict[typing.Const, typing.Const] = {"a": 5}
where typing.Const defaults to Any for an empty dict.

Re: A “frozen” dictionary for Python

#17

Post by _flux »

drhagen wrote: post #7

If this gets wide enough use, they could add an optimization for code like this: n = 1000 a = {} for i in range(n): a[i] = str(i) a = frozendict(a) # O(n) operation can be turned to O(1) It is relatively easy for the JIT to detect the `frozendict` constructor, the `dict` input, and the single reference immediately overwritten. Not sure if this would ever be worth it.

Wouldn't ref-counting CPython already know that a has a single reference, allowing this optimization without needing any particular smart JIT?

Re: A “frozen” dictionary for Python

#18

Post by _flux »

sundarurfriend wrote: post #12

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…

The key difference is what the GPT outlined: tuples have order for the fields and named tuples are not indexed by the name, but instead a field accessor is used, i.e. foo.bar vs foo["bar"]. In addition namedtuples can be indexed using that order like tuples can (foo[0]), which clearly isn't possible with dicts and would be quite confusing if dict had integer key.

So I think the differences aren't great, but they are sufficient. A frozendict is not going to be indexable by an integer. Python already has an abstract type for this, for mostly the use of type checking I imagine: https://docs.python.org/3/glossary.html#term-mapping

Documentation for namedtuple: https://docs.python.org/3/library/collections.html#collectio...

Re: A “frozen” dictionary for Python

#19

Post by anentropic »

codethief wrote: post #2

Next step: Auto-inferring the correct (most narrow) TypedDict type from a frozendict. (Think `const foo = { … } as const` in TypeScript.) I miss this TS feature in Python on the daily.

Agreed... but it shouldn't need a frozendict for this

IMHO TypedDict in Python are essentially broken/useless as is

What is needed is TS style structural matching, like a Protocol for dicts

Post reply on HN