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
Introduced as a possible solution to #12382; the theory is that most uses of serialize_as_any are because users want to respect subtyping properly.
This PR introduces a configuration option and runtime flag polymorphic_serialization which is used to enable serializing subclasses of models and dataclasses as the subclass, not as the base class.
To maintain backwards compatibility, the default is False - models and dataclasses will be serialized as the exact type in the schema.
When the config is set to True, then models and dataclasess will be serialized as their runtime type. This also respects any model serializer the subclass may be using.
Users can also pass polymorphic_serialization as a runtime option to the serialization functions; doing so will override the config value (i.e. can be globally enabled or disabled).
Points of Discussion for this PR
Annotated metadata
Not explored yet in this PR, an additional / alternative possibility could be to expose this as some kind of wrapper so that for foreign types one can use Annotated[ForeignModel, PolymorphicSerialization] to enable this even when the type didn't opt in.
(An Annotated form may remove the need for the global runtime override.)
Non-Pydantic types
This method cannot really ever work for types which Pydantic doesn't know how to serialize, e.g. subclass of int will not be serialized polymorphically. If the subclass had a __pydantic_serializer__ attribute it could in theory work, but I think that's the unlikely case.
More complicated is stdlib dataclasses and TypedDict. It might be reasonable to expect these to work, but I think that would require inspection of the subclass types at runtime and somehow caching a serializer for them. (i.e. a lot of runtime callback into Pydantic.)
Backwards compatibility
For the concern listed above on non-pydantic types, one way to introduce support for them later would be to have the runtime flag accept a set of types to serialize, e.g. polymorphic_serialization = {BaseModel, BaseDataClass, int}
... but another way to avoid the problem entirely would be to not have the global runtime flag and use the Annotated form to apply this behavior only to supported types.
The reason will be displayed to describe this comment to others. Learn more.
How hard would it be to fallback to inference (as serialize_as_any does) in this case? I'm worried we recommend switching from serialize_as_any to polymorphic_serialization but then users discover that it's "less powerful" in this case.
I guess it's a trade-off between not having it supported for now (and being able to implement it properly later), and having the limited inference behavior now (and users could as such rely on it) but such behavior changing when we implement it properly (and so is a behavior change for users already relying on it).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change Summary
(Imported from pydantic/pydantic-core#1881)
Introduced as a possible solution to #12382; the theory is that most uses of serialize_as_any are because users want to respect subtyping properly.
This PR introduces a configuration option and runtime flag polymorphic_serialization which is used to enable serializing subclasses of models and dataclasses as the subclass, not as the base class.
To maintain backwards compatibility, the default is
False- models and dataclasses will be serialized as the exact type in the schema.When the config is set to
True, then models and dataclasess will be serialized as their runtime type. This also respects any model serializer the subclass may be using.Users can also pass
polymorphic_serializationas a runtime option to the serialization functions; doing so will override the config value (i.e. can be globally enabled or disabled).Points of Discussion for this PR
AnnotatedmetadataNot explored yet in this PR, an additional / alternative possibility could be to expose this as some kind of wrapper so that for foreign types one can use
Annotated[ForeignModel, PolymorphicSerialization]to enable this even when the type didn't opt in.(An
Annotatedform may remove the need for the global runtime override.)Non-Pydantic types
This method cannot really ever work for types which Pydantic doesn't know how to serialize, e.g. subclass of
intwill not be serialized polymorphically. If the subclass had a__pydantic_serializer__attribute it could in theory work, but I think that's the unlikely case.More complicated is stdlib dataclasses and
TypedDict. It might be reasonable to expect these to work, but I think that would require inspection of the subclass types at runtime and somehow caching a serializer for them. (i.e. a lot of runtime callback intoPydantic.)Backwards compatibility
For the concern listed above on non-pydantic types, one way to introduce support for them later would be to have the runtime flag accept a set of types to serialize, e.g.
polymorphic_serialization = {BaseModel, BaseDataClass, int}... but another way to avoid the problem entirely would be to not have the global runtime flag and use the
Annotatedform to apply this behavior only to supported types.Related issue number
#12382
Checklist