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

81–90 of 172 posts

Re: A “frozen” dictionary for Python

#81

Post by grimgrin »

chistev wrote: post #24
grimgrin wrote: post #14

Earlier quoted context omitted.

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

This place hates ChatGPT and AI. Lol. Edit: Of course, I get down voted as I predicted I would. Lol.

you made a non-comment, that's why you're downvoted

comments don't have to be substantial, but they should be adding something that might merit more responses, or could. yours does not. what kind of reply could you even give to "this place [and so, its users] hates [thing]"

I'd ask you to qualify it, but you can't really qualify such a statement

Re: A “frozen” dictionary for Python

#82

Post by cylemons »

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.

How else would you "modify" immutable data other than by copying it?

Re: A “frozen” dictionary for Python

#83

Post by the__alchemist »

I wish Python could move away from types-as-mutability-determiners. Or paper over them; all could have mutable and non-mutable variants, with "to_mut()" and "to_immut()" methods. And in the same vein, explicit control over whether functions mutate a variable in place, or make a local copy. Python is my first lang, and I still am unable to consistently reason about these.

Re: A “frozen” dictionary for Python

#84

Post by Maledictus »

the__alchemist wrote: post #83

I wish Python could move away from types-as-mutability-determiners. Or paper over them; all could have mutable and non-mutable variants, with "to_mut()" and "to_immut()" methods. And in the same vein, explicit control over whether functions mutate a variable in place, or make a local copy. Python is my first lang, and I still am unable to consistently reason about these.

I love Ruby's .freeze

Re: A “frozen” dictionary for Python

#85

Post by ndr »

cylemons wrote: post #82
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.

How else would you "modify" immutable data other than by copying it?

You don't have to copy everything.

Look up persistent data structures [0]

The main trick is to store everything in a tree with a large branching factor.

The elements are on your leaves. When you want to make an edit you need to create only the nodes from the root to the actual leaf. Then you return the new root. Everything else you can share.

This is a log operation, normally implemented with branch 32.

It works with vectors as well as dicts. Creating a copy is constant, it's immutable can be shared freely (especially on GC'd languages).

Insert/Delete are O(log32(n)) instead of O(n) they'd be with a full copy.

[0] https://en.wikipedia.org/wiki/Persistent_data_structure#Pers...

Re: A “frozen” dictionary for Python

#86

Post by vanviegen »

zahlman wrote: post #62
jonathaneunice wrote: post #58

Earlier quoted context omitted.

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.

Indeed! I don't understand why it isn't more common for stdlibs to include key-ordered maps and sets. Way more useful than insertion ordering.

Re: A “frozen” dictionary for Python

#87

Post by thechao »

cylemons wrote: post #82
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.

How else would you "modify" immutable data other than by copying it?

And, yet, somehow, functional languages have been doing this since forever? I jest, I jest! There's an entire field of study focused on this! I'm no expert, but imagine you've got a singly-linked list, and we're going to allow only push_back() and pull_back() (no insert()). Let's go ahead and let multiple owners have at this list. If A does "pull_back()" what really happens is A has a local "tail" pointer that moves back along the end of the list and has a new belief about the end of the list. When A does "push_back()" it begins attaching links at its new tail. Since the links just "point backwards" without modifying the old links, this doesn't mutate the list "as is", it only mutates A's version of the list. So, if B is also looking at the list, it could just start doing "push_back()" and add its own "tail". The result is a data-structure that's a "bunch of shared singly linked lists" in a bush structure that's more akin to a tree than a singly linked list.

You can do the same thing with binary trees and other structures. It's more fiddly, and there's definitely places where single-ownership allows mutability "under the hood" for real performance gains, but that's the basic idea.

Re: A “frozen” dictionary for Python

#88

Post by codethief »

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.

After what release? Type checkers already support the various TypedDict PEPs, even those that haven't been accepted yet. Yet, none of them infers TypedDict types.

Re: A “frozen” dictionary for Python

#90

Post by codethief »

mrweasel wrote: post #16
dmurray wrote: post #13

Earlier quoted context omitted.

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.

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}
Post reply on HN