Pydantic

Pydantic is a data validation library that defines data models through standard Python type annotations. PyCharm provides dedicated support for Pydantic models, built on top of the same type engine that powers other type-hinting features.

The support covers pydantic.BaseModel and its subclasses, pydantic.dataclasses.dataclass, generic models, and related constructs such as Field, model and field validators, and ConfigDict options. PyCharm recognizes both Pydantic v1 and v2, but it does not read the options of the v1 class Config, such as allow_population_by_field_name.

Code insight for model fields

When you instantiate a Pydantic model, PyCharm treats the declared fields as keyword arguments of __init__ and provides the following code insight:

Completion of field names as keyword arguments, considering their declared types and default values.
Type checking of values passed for each field against the corresponding annotation.
An inspection that highlights missing required fields. A field declared with Annotated[..., Field(...)] and a default value after = is not required.
Navigation from a keyword argument in an __init__ call to the field declaration and back, including across subclasses and base classes.

            from pydantic import BaseModel

            class User(BaseModel):
                id: int
                name: str
                is_active: bool = True

            User(id=1, name="Alice")            # valid
            User(id="not-an-int", name="Steve") # type mismatch on id
            User(id=1)                          # name is missing
        

Field aliases and validation config

PyCharm accepts fields declared with an alias through Field(alias=...) as keyword arguments in constructor calls, without a false "unexpected argument" warning.

PyCharm respects the model configuration, so code insight in the editor matches the runtime validation behavior. PyCharm reads the options from the class keyword arguments, model_config, and the config argument or __pydantic_config__ of pydantic.dataclasses.dataclass. A subclass inherits the options of its base classes.

populate_by_name=True or validate_by_name=True: PyCharm accepts the field name in addition to its alias.
validate_by_alias=False: PyCharm accepts only the field name. By default, PyCharm accepts the alias.

PyCharm completes the names of ConfigDict options when you pass them as keyword arguments in the model's class header, so you do not need to recall the exact option name.

When both options are enabled, PyCharm accepts the field name and its alias as keyword arguments:

            from pydantic import BaseModel, Field

            class Model(BaseModel, validate_by_name=True, validate_by_alias=True):
                my_field: str = Field(alias='my_alias')

            Model(my_alias='foo')   # valid
            Model(my_field='foo')   # valid
        

PyCharm recognizes Field both in regular annotations and when it is used inside typing.Annotated:

            from typing import Annotated
            from pydantic import BaseModel, Field

            class User(BaseModel):
                name: Annotated[str, Field(alias='alias_name')] = "Lucy"
                age: int = Field(alias='alias_age', default=20)
        

Field constraint validation

PyCharm checks literal values passed to model constructors against the basic constraints declared on Field and reports a warning when a value does not satisfy them. The following constraints are recognized:

min_length and max_length for string fields.
gt, ge, lt, and le for numeric fields.

            from pydantic import BaseModel, Field

            class User(BaseModel):
                name: str = Field(..., min_length=2, max_length=50)
                age: int = Field(..., gt=0, lt=120)
                price: float = Field(..., gt=0)

            User(name="J", age=150, price=0)   # name is too short, age is out of range, price must be greater than 0
        

The constraints are also recognized when declared through typing.Annotated.

The check is performed by the Pydantic field constraint violation inspection. It does not run when an external type engine is selected.

Refactorings and validators

Renaming a model field also renames the keyword arguments in the __init__ calls of the model. Renaming such a keyword argument renames the field declaration.

In @field_validator, @field_serializer, and the legacy @validator, PyCharm resolves the field names that you pass as strings: you can complete them, navigate to the field declaration, and rename the field together with these strings.

When @field_validator, @model_validator, or @validator is combined with @classmethod, the Problematic nesting of decorators inspection does not report it.

27 October 2026