guacs
commented
8 months ago This is really nice! I had considered this approach a while back, but I faced an issue with how to pass the provider map. In the current test case, there wouldn't be any issues since both the parent and child are both dataclasses. The issue becomes when the parent and child are of different base classes. For example, consider a parent class being a pydantic model and a child class being a msgspec Struct. In this case, the child factory (i.e. the factory for the msgspec struct) would get the provider map of the parent pydantic model. However, the default MsgspecFactory overrides the default get_provider_map to inject types specific to msgspec.
The simplest option would be to tell users to not mix these models. It's fine if they mix pydantic with the Python builtins like dataclass, or typeddict since we don't have any special cases to handle there and, so, we don't override the get_provider_map. Maybe we could raise a warning if users are mixing it like that. I think, from a practical standpoint, this is a fine solution since it would probably be rare for them to be mixing something like pydantic and msgspec.
EDIT: Completely disregard what I said. I just realized you're using __extra_provider_map__ to handle this case. With your approach, the issue I mentioned above is not an issue anymore.
adhtruong
github-actions[bot]
Pull Request Checklist
Description
Close Issue(s)