basemodel

73 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

BaseModel.model_validate_strings() method

model_validate_strings() validates data as a dictionary (can be nested) with string keys and values and validates the data in JSON mode so that said strings can be coerced into the correct types. It accepts optional strict parameter for controlling validation strictness.

BaseModel.model_fields_set attribute

model_fields_set is an attribute that contains the set of fields which were explicitly provided when the model was initialized. Fields with default values that were not provided during instantiation are not included.

BaseModel.model_rebuild() method

model_rebuild() rebuilds the model schema. It is used when type annotations refer to symbols not defined when the model class is being created. It also supports building recursive generic models. In V2, it replaced update_forward_refs() from V1.

BaseModel.model_post_init() method

model_post_init() is called to perform additional actions after the model is instantiated and all field validators are applied. It receives a context parameter of type Any. It is recommended to use this instead of defining a custom __init__().

BaseModel.model_parametrized_name() method

model_parametrized_name() computes the class name for parametrizations of generic classes. It can be overridden to customize the default name generation for concrete subclasses.

BaseModel.model_computed_fields attribute

model_computed_fields is a mapping between computed field names and their definitions (ComputedFieldInfo instances).

Model signature generation

All Pydantic models have their signature generated based on their fields. The generated signature respects custom __init__ functions. To be included in the signature, a field's alias or name must be a valid Python identifier. Pydantic prioritizes a field's alias over its name when generating the signature.

Structural pattern matching support

Pydantic supports structural pattern matching for models as introduced by PEP 636 in Python 3.10. Match-case statements with Pydantic models are syntactic sugar for getting an attribute and either comparing it or declaring and initializing it.

Nested attributes with from_attributes

When using from_attributes to validate models from arbitrary objects, model instances are created from both top-level attributes and deeper-nested attributes as appropriate. This allows validating hierarchical object structures like ORM models with nested relationships.

Generic model type variable defaults and bounds

When leaving type variables unparametrized in generic models, if the type variable is bound or constrained to a specific type, it will be used. If it has a default type (per PEP 696), it will be used. For unbound or unconstrained type variables, Pydantic falls back to Any.

model_construct() performance note

In Pydantic V2, the performance gap between validation and model_construct() has been narrowed considerably. For simple models, validation may even be faster. If using model_construct() for performance reasons, profiling is recommended before assuming it is actually faster.

Immutability note for frozen models

In Python, immutability is not enforced. Even with frozen=True, developers have the ability to modify mutable nested objects. The frozen setting prevents changes to top-level attributes but not to nested mutable objects like dictionaries or lists.

model_rebuild() with generics and forward annotations

When calling model_rebuild() on the outermost model with generics or recursive models, it builds a core schema used for validation of the whole model including nested models. All types at all levels need to be ready before model_rebuild() is called.

Give your agent this brain