-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow different serializer to an Annotated
type for "python" and "json" mode
#8086
Comments
Hi @ChillPC, This seems like a great idea. You've brought up some great points about varied use cases for this kind of feature. Do you have any interest in opening a PR adding support for this kind of logic? Perhaps this is something we could fit into our next minor release 😄. |
Hello @sydney-runkle ! I sure would be interested but :
Difficulties
The problem rise on the signature of the In the definition of schema['serialization'] = core_schema.plain_serializer_function_ser_schema(
...,
when_used=self.when_used,
...
) Would it be acceptable to store the newly created Api considerationFor when_used: Literal['always', 'unless-none', 'json', 'json-unless-none'] | set[str] = {'python', 'json'} But the And what about the key for the serializer to fallback to ? Would it be a magic string like Sorry if it is a lot of question 😅 I just want to be sure I am going on the right direction |
Also has this issue today. We are allowing to serializer the model into python and json string. Why we do not allow the same keys for PlainSerializer? Why we allow I would propose to have 2 different variables instead of a lot of
Am I missing something? |
Apologies for the delay. We're excited that you're going to help implement this! I think that @davidhewitt will be the best person to answer these questions. Specifically, DH, what do you think about these two inquiries?
In other words, should we expand the definition of
Good question. I think having two indicators here could be useful.
The Feel free to reach out if you have more questions. I'll be much more prompt with responses moving forward. |
I think there are two different feature requests here, and let's separate them. Custom modes like For "python" and "json" mode, this is already supported in schema_python = some_validation_schema()
schema_json = schema_python.copy()
schema_python['serialization'] = python_serializer
schema_json['serialization'] = json_serializer
core_schema.json_or_python_schema(json_schema=schema_json, python_schema=schema_python) So I think this can be implemented without any Rust changes, just need to work out a desirable way to expose this in the Pydantic API and build a schema like the above. |
Hello @davidhewitt , |
Going to remove this from the v2.8 milestone - doesn't fit in the timeline. Happy to put in another milestone when it makes sense! |
Initial Checks
Description
A demo of how code might look when using the feature
Either give the possibility to have as many mode of serialization you want :
Or at least differentiate the mode "python" and "json" :
Your use case(s) for the feature
I work with mongodb and work with dates. It needs to have 3 different forms:
datetime.date
in the business logicdatetime.datetime
when dumping into mongo because there is no bson type representing only the date part of a datetimestr
in formatYYYYMMDD
for the apiMy first idea was to have multiple serializer on an
Annotated
type like this :I thought that the 2nd
PlainSerializer
would override the 1st one only on "json" mode but serializing aBaseModel
with this field give :Why the feature should be added to pydantic (as opposed to another library or just implemented in your code)
This touch the serialization on the field level and not the model level. Custom user code would certainly be too cumbersome.
Affected Components
.model_dump()
and.model_dump_json()
model_construct()
, pickling, private attributes, ORM modeThe text was updated successfully, but these errors were encountered: