[codethief]

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.

¹) https://peps.python.org/pep-0764/

[xg15]

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

[codethief]

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.

[xg15]

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.

[mvieira38]

When, if ever, do you use TypedDicts?

[tiltowait]

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.

[JohnKemeny]

Do you seriously have difficulties explaining when to use a class and when to use a dictionary?!

[codethief]

You can create dictionaries on the fly. But dataclass objects require defining that dataclass first. The type safety (and LSP support) story for accessing individual dataclass fields is better than for accessing dict items (sometimes even when they are TypedDicts), but for iterating over all fields it's worse. dataclasses are nominal types and can contain additional logic, TypedDicts are structural ones, overall simpler, can be more convenient and lead to looser coupling. Dataclasses use metaclass and decorator magic while TypedDics are just plain dicts. Etc.

Let me make this more concrete: Those sysadmins frequently need to process and pass around complex (as in heavily nested) structured data. The data often comes in the form of singleton objects, i.e. they are built in single place, then used in another place and then thrown away (or merged into some other structure). In other words, any class hierarchy you build represents boilerplate code you'll only ever use once and which will be annoying to maintain as you refactor your code. Do you pick dataclasses or TypedDicts (or something else) for your map data structures?

In TypeScript you would just use `const data = <heavily nested object> as const` and be done with it.

[quietbritishjim]

The line is seriously blurred.