A Python dict that can report which keys you did not use • Hacker News Board

Re: A Python dict that can report which keys you did not use

#31

Post by xg15 » Wed, Jul 30, 2025, 7:53 PM UTC

codethief wrote: post #25

Only tangentially related but I am really excited about PEP 764¹ (inline typed dictionaries). If it gets accepted, we can finally replace entire hierarchies of dataclasses with simple nested dictionary types and call it a day. I am currently teaching (typed) Python to a team of Windows sysadmins and it's been incredibly difficult to explain when to use a dataclass, a NamedTuple, a Pydantic model, or a dictionary. ¹)…

To be honest, that proposal sounds like it would make the problem even worse, by blurring the line between dicts and dataclasses even more.

Re: A Python dict that can report which keys you did not use

#32

Post by eurleif » Wed, Jul 30, 2025, 8:00 PM UTC

Jaxan wrote: post #21

jgalt212 wrote: post #12

why not inside of __init__ self.accessed_keys = set() instead of @property def accessed_keys(self): return self._accessed_keys

With the @property you only get the “getter” and not the “setter”.

But that doesn't accomplish much, because you can still do: `d.accessed_keys.add('foo')`.

Re: A Python dict that can report which keys you did not use

#33

Post by codethief » Wed, Jul 30, 2025, 8:04 PM UTC

xg15 wrote: post #31

codethief wrote: post #25

Only tangentially related but I am really excited about PEP 764¹ (inline typed dictionaries). If it gets accepted, we can finally replace entire hierarchies of dataclasses with simple nested dictionary types and call it a day. I am currently teaching (typed) Python to a team of Windows sysadmins and it's been incredibly difficult to explain when to use a dataclass, a NamedTuple, a Pydantic model, or a dictionary. ¹)…

To be honest, that proposal sounds like it would make the problem even worse, by blurring the line between dicts and dataclasses even more.

How does creating anonymous TypedDicts (and allowing them to be nested on the fly) blur the line "even more" when those features are not supported by dataclasses?

I mean I agree w.r.t. the blurriness in general but this PEP is not going to change anything about that, in neither direction.

Re: A Python dict that can report which keys you did not use

#34

Post by quietbritishjim » Wed, Jul 30, 2025, 8:12 PM UTC

ok123456 wrote: post #11

quietbritishjim wrote: post #7

Earlier quoted context omitted.

From right above where you linked to: > The need for this class has been partially supplanted by the ability to subclass directly from dict; however, this class can be easier to work with because the underlying dictionary is accessible as an attribute. Sounds like (unless you need the dict as a separate data member) this class is a historical artefact. Unless there's some other issue you know of not mentioned in the…

dict doesn't follow the usual object protocol, and overloaded methods are runtime dependent. It's only guaranteed that non-overloaded methods are resolved least surprisingly.

I think you mean overridden (i.e. defined in both base class and derived class) rather than overloaded (i.e. defined more than once in a single place but with different argument types, as least from a typing point of view [1]). Your comment seriously confused me till I figured that out.

[1] https://typing.python.org/en/latest/spec/overload.html

Even then, to be honest I'm a bit sceptical. Can you point at a link in the official documentation that says overriding methods of dictionaries may not work? I would have thought the link to UserDict would have mentioned that if true. What do you mean they are "runtime dependent"?

Re: A Python dict that can report which keys you did not use

#35

Post by mvieira38 » Wed, Jul 30, 2025, 8:27 PM UTC

codethief wrote: post #25

Only tangentially related but I am really excited about PEP 764¹ (inline typed dictionaries). If it gets accepted, we can finally replace entire hierarchies of dataclasses with simple nested dictionary types and call it a day. I am currently teaching (typed) Python to a team of Windows sysadmins and it's been incredibly difficult to explain when to use a dataclass, a NamedTuple, a Pydantic model, or a dictionary. ¹)…

When, if ever, do you use TypedDicts?

Re: A Python dict that can report which keys you did not use

#36

Post by mrits » Wed, Jul 30, 2025, 8:51 PM UTC

For giant dicts a bloomfilter would work great here

Re: A Python dict that can report which keys you did not use

#37

Post by 9dev » Wed, Jul 30, 2025, 9:21 PM UTC

mont_tag wrote: post #13

ok123456 wrote: post #4

If you're inheriting from dict to extend its behavior, there are a lot of side effects with that, and it's recommended to use https://docs.python.org/3/library/collections.html#collectio... instead.

No, that is not the recommendation. People routinely and reliably inherit from dict. The UserDict class is mostly defunct and is only still in the standard library because there were a few existing uses that were hard to replace (such as avoiding base class conflicts in multiple inheritance).

Ah, Python. The language where nobody agrees on the right way to do things, ans just does their own instead. Five ways to describe an object of a certain shape? Six package managers, with incompatible but overlapping ways to publish packages, but half of them without a simple way to update dependencies? Asynchronous versions of everything? Metaprogramming that makes Ruby blush? Yes! All of it! Lovely.

Re: A Python dict that can report which keys you did not use

#38

Post by [deleted] » Wed, Jul 30, 2025, 10:07 PM UTC

boothby wrote: post #16

notatallshaw wrote: post #10

Earlier quoted context omitted.

setdefault was a go to method before defaultdict was added to the collections module in Python 2.5, which replaced the biggest use case.

It's been some time since I last benchmarked defaultdict but last time I did (circa 3.6 and less?), it was considerably slower than judicious use of setdefault.

[deleted]

Re: A Python dict that can report which keys you did not use

#39

Post by tiltowait » Wed, Jul 30, 2025, 10:12 PM UTC

mvieira38 wrote: post #35

codethief wrote: post #25

Only tangentially related but I am really excited about PEP 764¹ (inline typed dictionaries). If it gets accepted, we can finally replace entire hierarchies of dataclasses with simple nested dictionary types and call it a day. I am currently teaching (typed) Python to a team of Windows sysadmins and it's been incredibly difficult to explain when to use a dataclass, a NamedTuple, a Pydantic model, or a dictionary. ¹)…

When, if ever, do you use TypedDicts?

I use them for API responses/requests where dataclasses/pydantic don't add much value and introduce extra function calls and overhead. It's most common when part of the response from one API gets shuttled off to another. There's often no value in initializing a model object, but it's still handy to have some form of type-checking as you construct the next API call.

Re: A Python dict that can report which keys you did not use

#40

Post by xg15 » Wed, Jul 30, 2025, 10:25 PM UTC

codethief wrote: post #33

xg15 wrote: post #31

Earlier quoted context omitted.

To be honest, that proposal sounds like it would make the problem even worse, by blurring the line between dicts and dataclasses even more.

How does creating anonymous TypedDicts (and allowing them to be nested on the fly) blur the line "even more" when those features are not supported by dataclasses? I mean I agree w.r.t. the blurriness in general but this PEP is not going to change anything about that, in neither direction.

True, but I think what I don't like is that this PEP essentially creates an entire new way of "type definitions" that is separate from the type definitions we already have.

I get the rationale for "anonymous strict" return types, but then I think a better way would be to think up some way to accomplish that for dataclasses.