You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Code review request: support for asdict returning TypedDict #10104
I'm sorry for abusing the issue tracker, but I'm not sure how else to notify someone who could perform a code-review (I did try pinging/mentions). And no worries of course :)
I have brought this PR up-to-date and passing tests again and would like to request a re-review: #8583
@JukkaL Perhaps you have the time at some point to take a look or could ping someone who does?
Although the feature is already mentioned in #5152, I'll try to pitch it.
The pitch:
I have a dataclass that happens to have the same (or a subset of the same) fields as another class.
The list is potentially long, and each one has a different type.
I would like to construct the class out of the dataclass, without having to explicitly list each field as an argument to the class's constructor. It's easy to do this at run-time, but I would like to ensure that it is also statically checked.
To avoid listing each field manually, I can take advantage of splatting the TypedDict.
This should allow mypy to type-check that I do in fact pass the correct arguments to the class constructor.
@dataclassclassFooEntity:
bar: str# long list of fields...classFoo:
def__init__(bar: str, ...): passdefcreate_foo_from_entity(foo: FooEntity) ->Foo:
returnFoo(**asdict(foo))
I could think of a similar example with a function instead of a class constructor.
You could also have a case where a function is expected to return a certain TypedDict (let's say it's part of an existing API), and you have decided to use dataclasses as your internal representation, among other reasons, because they can have methods, are mutable, and possible to build-up incrementally. To avoid having to explicitly construct the TypedDict from the dataclass (which may include nested dataclasses), you could just call asdict on it and still be assured that the types match what is expected.
I can't otherwise see many use cases for this, as I would assume that many people just directly serialize the return value of asdict, and so don't use it in a precisely-typed manner.
Finally, as a future idea, it would be interesting to be able to use a type annotation AsDict[MyDataclass] to represent the TypedDict returned by calling asdict(instance_of_my_dataclass). This would allow the information about which TypedDict was returned to flow across function boundaries.
The problem I see with this proposal is that asdict is documented to return a dict. A TypedDict is not type compatible with dict; it's a subclass of Mapping. If asdict were changed to return a TypedDict, it would break backward compatibility for code that (correctly) assumes that the return type of asdict is a dict.
For this idea to work, I think there would need to be a new function such as asmapping. At runtime, it would do the same thing as asdict, but its type definition would be different so it could be used in situations where a TypedDict is desired.
The problem I see with this proposal is that asdict is documented to return a dict. A TypedDict is not type compatible with dict; it's a subclass of Mapping. If asdict were changed to return a TypedDict, it would break backward compatibility for code that (correctly) assumes that the return type of asdict is a dict.
It's worth noting that with Intersection type (potentially soon? 🤞) asdict could be correctly typed as dict & TypedDict[…] AFAIC.
Activity
tony commentedon Jul 30, 2022
Does anyone know a workaround to get
asdict+TypedDictworking w/ mypy?erictraut commentedon Aug 25, 2023
The problem I see with this proposal is that
asdictis documented to return adict. ATypedDictis not type compatible withdict; it's a subclass ofMapping. Ifasdictwere changed to return aTypedDict, it would break backward compatibility for code that (correctly) assumes that the return type ofasdictis adict.For this idea to work, I think there would need to be a new function such as
asmapping. At runtime, it would do the same thing asasdict, but its type definition would be different so it could be used in situations where aTypedDictis desired.m-aciek commentedon Aug 31, 2025
@tony there's ubertyped library that can be used as a workaround AFAIC.
m-aciek commentedon Aug 31, 2025
It's worth noting that with
Intersectiontype (potentially soon? 🤞)asdictcould be correctly typed asdict & TypedDict[…]AFAIC.