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
Defining custom type adapters for third party types by wrapping them in Annotated creates a confusing user experience. For example, say I'm creating a custom adapter for a popular library like Pandas. Currently to make this work you need to do something like the following:
However, users would prefer to avoid using AdaptedDataFrame in favor of the normal pd.DataFrame since the former adds a layer of indirection. This is particularly confusing to explain to scientists since they don't want to, and shouldn't have to concern themselves with the details of how Pydantic figures out how to validate and serialize things. Instead, they'd much prefer for Pydantic to somehow automatically figure out how to treat pd.DataFrame as AdaptedDataFrame so they can just write:
Annotating things with pd.DataFrame won't "just work" unless Pandas decides to add native support for Pydantic. Baring that possibility, a "thirdy party type registry" could be a suitable alternative. The idea being that, if it were possible to declare some mapping from thirdy party types to their custom adapters Pydantic could automatically treat all pd.DataFrame annotations as AdaptedDataFrame. As an example, perhaps you could declare a type_registry as part of the model's:
Generics seem like they might be hard to treat properly. Consider ThirdPartyType[T] and what ought to happen if the custom type adapter should vary depending on how T is bound? With the Annotated wrapper, while it's clumsy, you could still declare the adapted aliases as follows:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The Problem
Defining custom type adapters for third party types by wrapping them in
Annotated
creates a confusing user experience. For example, say I'm creating a custom adapter for a popular library like Pandas. Currently to make this work you need to do something like the following:However, users would prefer to avoid using
AdaptedDataFrame
in favor of the normalpd.DataFrame
since the former adds a layer of indirection. This is particularly confusing to explain to scientists since they don't want to, and shouldn't have to concern themselves with the details of how Pydantic figures out how to validate and serialize things. Instead, they'd much prefer for Pydantic to somehow automatically figure out how to treatpd.DataFrame
asAdaptedDataFrame
so they can just write:A Solution?
Annotating things with
pd.DataFrame
won't "just work" unless Pandas decides to add native support for Pydantic. Baring that possibility, a "thirdy party type registry" could be a suitable alternative. The idea being that, if it were possible to declare some mapping from thirdy party types to their custom adapters Pydantic could automatically treat allpd.DataFrame
annotations asAdaptedDataFrame
. As an example, perhaps you could declare atype_registry
as part of the model's:Challenges
Generics seem like they might be hard to treat properly. Consider
ThirdPartyType[T]
and what ought to happen if the custom type adapter should vary depending on howT
isbound
? With theAnnotated
wrapper, while it's clumsy, you could still declare the adapted aliases as follows:Ideally you'd be able to declare the mapping to the custom adaptors as:
But getting this to work in practice seems non-trivial.
Notes
This request seems similar to #8279
Beta Was this translation helpful? Give feedback.
All reactions