configuration

28 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

ConfigDict.validate_by_name parameter

ConfigDict.validate_by_name is a boolean parameter that controls whether field names (not aliases) are used for validation. Default value is False.

validate_by_alias and validate_by_name cannot both be False

You cannot set both ConfigDict.validate_by_alias and ConfigDict.validate_by_name to False. A user error is raised if both are set to False.

validate_by_alias and validate_by_name both True ConfigDict example

from pydantic import BaseModel, ConfigDict, Field class Model(BaseModel): my_field: str = Field(validation_alias='my_alias') model_config = ConfigDict(validate_by_alias=True, validate_by_name=True) print(repr(Model(my_alias='foo'))) #> Model(my_field='foo') print(repr(Model(my_field='foo'))) #> Model(my_field='foo')

ConfigDict.serialize_by_alias parameter

ConfigDict.serialize_by_alias is a boolean parameter that controls whether aliases are used for serialization. Default value is False.

serialize_by_alias ConfigDict example

from pydantic import BaseModel, ConfigDict, Field class Model(BaseModel): my_field: str = Field(serialization_alias='my_alias') model_config = ConfigDict(serialize_by_alias=True) m = Model(my_field='foo') print(m.model_dump()) #> {'my_alias': 'foo'}

ConfigDict.validate_by_alias parameter

ConfigDict.validate_by_alias is a boolean parameter that controls whether aliases are used for validation. Default value is True.

with_config decorator for standard library types

The @with_config decorator from pydantic.config can be used to set configuration on standard library dataclasses or TypedDict classes, avoiding static type checking errors with TypedDict. Example: @with_config(ConfigDict(str_to_lower=True)) class Model(TypedDict): x: str

validate_call decorator supports custom configuration

The @validate_call decorator supports setting custom configuration via a dedicated section in its documentation.

Configuration inheritance in BaseModel

Configuration is inherited from parent BaseModel classes. Child classes can be created with custom configuration to change global behavior.

Configuration merging in BaseModel subclasses

When subclasses provide configuration via model_config, it is merged with the parent configuration. Child class configuration values override parent values with the same key. Example: Parent defines model_config with extra='allow' and str_to_lower=False, child defines model_config with str_to_lower=True, resulting in merged config with both keys where child str_to_lower overrides parent.

BaseModel MRO limitation in multiple inheritance

If a model inherits from multiple bases, Pydantic currently does not follow the Python Method Resolution Order (MRO) for configuration.

plugin_settings configuration for Pydantic plugins

The plugin_settings configuration value passes options to Pydantic plugins as a dictionary keyed by plugin name. Each plugin reads only its own entry. Example used by Logfire plugin: class User(BaseModel, plugin_settings={'logfire': {'record': 'failure'}}): name: str; email: str

Configuration non-propagation for Pydantic models and dataclasses

Configuration is not propagated to nested Pydantic models or Pydantic dataclasses when used as field annotations. Each model has its own configuration boundary and maintains its own configuration settings independently.

Configuration propagation with stdlib type override

When a stdlib dataclass or TypedDict has its own configuration set via __pydantic_config__ or @with_config, that configuration takes precedence and prevents propagation from parent Pydantic models.

Configuration propagation for stdlib types

Configuration is propagated to nested standard library dataclasses and TypedDict types when used as field annotations, unless the nested type has its own configuration set via __pydantic_config__ or @with_config.

ConfigDict class controls Pydantic behavior

The behaviour of Pydantic can be controlled via configuration values documented on the ConfigDict class.

model_config class attribute for BaseModel configuration

On Pydantic BaseModel, configuration can be specified using the model_config class attribute set to a ConfigDict instance or plain dictionary. Example: class Model(BaseModel): model_config = ConfigDict(str_max_length=5)

Class arguments for BaseModel configuration

Pydantic BaseModel configuration can also be specified using class arguments passed directly to the class definition. Unlike model_config, static type checkers will recognize class arguments. Example: class Model(BaseModel, frozen=True): a: str

Pydantic V1 Config class deprecated

In Pydantic V1, the Config class was used for configuration. This is still supported in V2 but is deprecated.

__pydantic_config__ attribute for standard library types

For standard library dataclasses or TypedDict classes, configuration can be set using the __pydantic_config__ class attribute with a ConfigDict instance.

Strict mode conversion allowances

The Strict column in the conversion table indicates which type conversions are allowed when validating in Strict Mode.

Conversion table documentation structure

Pydantic provides a conversion table that documents how data is converted during validation in both strict and lax modes. The table is organized into five tabs: All (all conversions), JSON (JSON conversions), JSON - Strict (JSON conversions in strict mode), Python (Python conversions), and Python - Strict (Python conversions in strict mode).

Polymorphic serialization configuration

Polymorphic serialization can be configured at two levels: (1) Configuration level using polymorphic_serialization in the model's ConfigDict, (2) Runtime level using the polymorphic_serialization argument in serialization methods like model_dump() and model_dump_json(). Runtime setting overrides configuration. This applies only to Pydantic models and Pydantic dataclasses, not stdlib dataclasses.

Polymorphic serialization example

from pydantic import BaseModel class User(BaseModel): name: str class UserLogin(User): password: str class OuterModel(BaseModel): user: User outer_model = OuterModel( user=UserLogin(name='pydantic', password='password'), ) print(outer_model.model_dump()) #> {'user': {'name': 'pydantic'}} print(outer_model.model_dump(polymorphic_serialization=True)) #> {'user': {'name': 'pydantic', 'password': 'password'}}

serialize_as_any runtime parameter

The serialize_as_any parameter can be passed to serialization methods (model_dump(), model_dump_json(), etc.) to enable or disable duck-typed serialization for all values in the serialization call. This applies to all nested types and overrides any field-level or configuration-level settings.

serialize_as_any runtime example

from pydantic import BaseModel class User(BaseModel): name: str class UserLogin(User): password: str class OuterModel(BaseModel): user1: User user2: User user = UserLogin(name='pydantic', password='password') outer_model = OuterModel(user1=user, user2=user) print(outer_model.model_dump(serialize_as_any=True)) """ { 'user1': {'name': 'pydantic', 'password': 'password'}, 'user2': {'name': 'pydantic', 'password': 'password'}, } """ print(outer_model.model_dump(serialize_as_any=False)) #> {'user1': {'name': 'pydantic'}, 'user2': {'name': 'pydantic'}}

Subclass serialization with polymorphic behavior disabled

When polymorphic_serialization is disabled (default in V2), subclass instances are serialized according to the type annotation, not the runtime type. Only fields declared on the annotated type are included in serialization, excluding fields only in the subclass.

Subclass serialization example with default behavior

from pydantic import BaseModel class User(BaseModel): name: str class UserLogin(User): password: str class OuterModel(BaseModel): user: User user = UserLogin(name='pydantic', password='hunter2') m = OuterModel(user=user) print(m) #> user=UserLogin(name='pydantic', password='hunter2') print(m.model_dump()) #> {'user': {'name': 'pydantic'}}

Give your agent this brain