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

131–140 of 172 posts

Re: A “frozen” dictionary for Python

#131

Post by morshu9001 »

tehnub wrote: post #108
morshu9001 wrote: post #104

Earlier quoted context omitted.

Same. Recently I saw interview feedback where someone complained that the candidate used OrderedDict instead of the built-in dict that is now ordered, but they'll let it slide... As if writing code that will silently do different things depending on minor Python version is a good idea.

Well it's been guaranteed since 3.7 which came out in 2018, and 3.6 reached end-of-life in 2021, so it's been a while. I could see the advantage if you're writing code for the public (libraries, applications), but for example I know at my job my code is never going to be run with Python 3.6 or older.

Yeah, if you have that guarantee then I wouldn't fault anyone for using dict, but also wouldn't complain about OrderedDict.

Re: A “frozen” dictionary for Python

#132

Post by dontlaugh »

no_wizard wrote: post #116
xen0 wrote: post #113

Earlier quoted context omitted.

It's sometimes nice to be deterministic. I don't often care about a specific order, only that I get the same order every time.

Thinking about this upfront for me, I am actually wondering why this is useful outside of equality comparisons. Granted, I live and work in TypeScript, where I can't `===` two objects but I could see this deterministic behavior making it easier for a language to compare two objects, especially if equality comparison is dependent on a generated hash. The other is guaranteed iteration order, if you are reliant on the i…

Being able to parse something into a dict and then serialise it back to the same thing is a bit easier. Not a huge advantage, though.

Re: A “frozen” dictionary for Python

#133

Post by [deleted] »

krick wrote: post #126
morshu9001 wrote: post #106

Earlier quoted context omitted.

You can't really tell though. Maybe the dict is frozen but the values inside aren't. C++ tried to handle this with constness, but that has its own caveats that make some people argue against using it.

Indeed. So I don't really understand what this proposal tries to achieve. It even explicitly says that dict → frozendict will be O(n) shallow-copy, and the contention is only about O(n) part. So… yeah, I'm sure they are useful for some cases, but as Raymond has said — it doesn't seem to be especially useful, and I don't understand what people ITT are getting excited about.

[deleted]

Re: A “frozen” dictionary for Python

#134

Post by rcxdude »

pkulak wrote: post #112
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...

This is why I love how Rust approached this; almost by accident to make borrow checking work. Every reference is either mutable or not, and (with safe code), you can't use an immutable reference to get a mutable reference anywhere down the chain. So you can slowly construct a map through a mutable reference, but then return it out of a function as immutable, and that's the end of it. It's no longer ever mutable, and…

Only if you're returning a reference or wrapping it in something that will only ever return a reference. If you return an object by value ('owned'), then you can do what you like with it and 'mut' is just an light guardrail on that particular name for it.

Re: A “frozen” dictionary for Python

#135

Post by mrweasel »

codethief wrote: post #90
mrweasel wrote: post #16

Earlier quoted context omitted.

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.

Not sure we're talking about the same thing. Inline TypedDicts are already in the process of being formalized, see https://peps.python.org/pep-0764/ , and have experimental support in e.g. Pyright. What I meant was that foo = {"a": 5} should be inferred as foo: TypedDict[{ "a": Literal[5] }] = {"a": 5}

Ah, I didn't know about PEP 795. I don't really know if I like it though. It looks like something someone invented because they don't want to write classes or specifically want to be able to access a data structure like a dict, for whatever reason.

It basically provides data types, but also ensures that you have no easy way to reuse them, and it will miss cases where two data structures happen to have the same signature.

It's getting a little messy when we have class, namedtuple and TypedDict, which all can do much the same thing.

Re: A “frozen” dictionary for Python

#136

Post by minitech »

tremon wrote: post #97
chriswarbo wrote: post #95

Earlier quoted context omitted.

> I don't see why hasattr(mySet, 'pop') should be a problem here? I never said it's a problem (and I never said it's not!). I was specifically addressing two things: - The "theoretical" nature of the question I quoted (i.e. ignoring other aspects like subjectivity, practicality, convention, etc.) - The reasoning about "Liskov violation", which was quoted further up this thread. For context, here's Liskov's definition…

> > Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T. This says "if hasattr(parent, 'pop') == True then hasattr(child, 'pop') must be True". This is not violated in this case, since hasattr(parent, 'pop') is False. If you want to extend the above definition so that negative proofs concerning the parent should als…

The property in question is `hasattr(x, "pop") is False`.

> If you want to extend the above definition so that negative proofs concerning the parent should also hold true for the child, then subtyping becomes impossible since all parent and child types must be identical, by definition.

The distinction isn’t “negative proofs”, but yes, that’s their point. In Python, you have to draw a line as to which observable properties are eligible.

Re: A “frozen” dictionary for Python

#137

Post by vlovich123 »

pkulak wrote: post #112
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...

This is why I love how Rust approached this; almost by accident to make borrow checking work. Every reference is either mutable or not, and (with safe code), you can't use an immutable reference to get a mutable reference anywhere down the chain. So you can slowly construct a map through a mutable reference, but then return it out of a function as immutable, and that's the end of it. It's no longer ever mutable, and…

You cannot return an immutable version. You can return it owned (in which case you can assign/reassign it to a mut variable at any point) or you can take a mut reference and return an immutable reference - but whoever is the owner can almost always access it mutably.

Re: A “frozen” dictionary for Python

#138

Post by pkulak »

vlovich123 wrote: post #137
pkulak wrote: post #112

Earlier quoted context omitted.

This is why I love how Rust approached this; almost by accident to make borrow checking work. Every reference is either mutable or not, and (with safe code), you can't use an immutable reference to get a mutable reference anywhere down the chain. So you can slowly construct a map through a mutable reference, but then return it out of a function as immutable, and that's the end of it. It's no longer ever mutable, and…

You cannot return an immutable version. You can return it owned (in which case you can assign/reassign it to a mut variable at any point) or you can take a mut reference and return an immutable reference - but whoever is the owner can almost always access it mutably.

Arg, you’re right. Not sure what I was thinking there. I still think my point stands, because you get the benefits of immutability, but yeah, I didn’t explain it well.

Re: A “frozen” dictionary for Python

#139

Post by vlovich123 »

I’m curious why the dict->frozendict operation is not an O(1) operation when there’s a refcnt of 1 on the dict - that resolves the spooky action at a distance problem raised and solves the performance for the most common usage pattern (build up the dict progressively and convert to a frozendict for concurrent reads).

Re: A “frozen” dictionary for Python

#140

Post by minitech »

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…

On top of generating types dynamically being slow and bad as quietbritishjim said, “str values that also happen to be valid identifiers” is a very limiting dict key requirement.
Post reply on HN