Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update json_encoders docs #6848

Merged
merged 1 commit into from Jul 25, 2023
Merged

Update json_encoders docs #6848

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/blog/pydantic-v2.md
View file
Open in desktop
Expand Up @@ -755,7 +755,7 @@ The emoji here is just for variation, I'm not frowning about any of this, these
remove the functionality, but it's something of a historical curiosity that it lives within pydantic,
perhaps it should move to a separate package, perhaps installable alongside pydantic with
`pip install pydantic[settings]`?
8. The following `Config` properties will be removed:
8. The following `Config` properties will be removed or deprecated:
* `fields` - it's very old (it pre-dates `Field`), can be removed
* `allow_mutation` will be removed, instead `frozen` will be used
* `error_msg_templates`, it's not properly documented anyway, error messages can be customized with external logic if required
Expand Down
5 changes: 1 addition & 4 deletions docs/migration.md
View file
Open in desktop
Expand Up @@ -117,12 +117,9 @@ to help ease migration, but calling them will emit `DeprecationWarning`s.
[`@computed_field`](api/fields.md#pydantic.fields.computed_field) decorators, which each address various
shortcomings from Pydantic V1.
* See [Custom serializers](usage/serialization.md#custom-serializers) for the usage docs of these new decorators.
* Due to performance overhead and implementation complexity, we have now removed support for specifying
* Due to performance overhead and implementation complexity, we have now deprecated support for specifying
`json_encoders` in the model config. This functionality was originally added for the purpose of achieving custom
serialization logic, and we think the new serialization decorators are a better choice in most common scenarios.
However, if your usage of `json_encoders` is not compatible with the new serialization decorators,
please create a GitHub issue letting us know. See [Custom data types](usage/types/custom.md) for further
details.
* We have changed the behavior related to serializing subclasses of models when they occur as nested fields in a parent
model. In V1, we would always include all fields from the subclass instance. In V2, when we dump a model, we only
include the fields that are defined on the annotated type of the field. This helps prevent some accidental security
Expand Down