The Pydantic PyCharm plugin makes BaseModel constructors visible to the IDE

BaseModel constructors, finally visible to the IDE

The problem the plugin exists to solve is stated in the README as a link to a pydantic issue: autocompletion when instantiating BaseModel objects. The reason PyCharm gets it wrong is structural. A pydantic model does not write an __init__ method, its fields are collected at class definition time and turned into a constructor signature, and the static analyser has no way to see that. So the IDE reports a constructor with no arguments, and every call site is a hole in the type information.

The plugin closes that hole with model specific inspection and autocompletion for subclasses of pydantic.BaseModel, giving each subclass its own __init__ signature. Alongside that it adds model specific argument type checking for the same subclasses.

The rest of the feature set is the same idea applied to the places where pydantic breaks the ordinary Python rules. You can search related fields by class attributes and __init__ keyword arguments with Ctrl+B and Cmd+B, and there is a quick fix that inserts unfilled arguments for a model subclass, which is the practical answer to a constructor with twenty optional fields.

The plugin is a JetBrains plugin written in Kotlin, published on the JetBrains Marketplace as plugin 12861, and the primary language of the repository is Kotlin with a Gradle build.

Renaming a field becomes a real refactoring

The most useful feature on the list is not an inspection at all, it is rename support. The plugin provides refactoring for renaming fields of BaseModel subclasses, and the detail in the README explains why that is not something PyCharm does by default.

When you rename a field in the model definition or in the keyword arguments of an __init__ call, PyCharm presents a dialog offering the choice to automatically rename the keyword where it occurs in a model initialisation call. So the rename propagates to the call sites, which is the behaviour you would get if the model had a real constructor.

The same machinery is what makes the Ctrl+B and Cmd+B navigation work. Finding the usages of a field means finding both the class attribute and the keyword argument in construction calls, and a plugin that understands the model can follow both.

The practical value is larger than the feature list suggests. In a pydantic codebase the field name is the API, it is what appears in the constructor call, in the schema, in the validation error and often in the request body of a FastAPI endpoint, and a rename that misses one of those places is a bug. Support for jumping to the validator associated with a field, and for refactoring inside a validator, follows from the same model awareness.

A type inspection that understands pydantic rules

The plugin provides its own inspection for type checking, and the README is careful about the distinction: the inspection is compatible with pydantic, and it supports parsable-type. The detail of how it behaves is in the type-checking section of the plugin documentation.

That compatibility is the whole point. A model field declared as a pydantic type is not the same as a plain annotation, because pydantic coerces values and accepts a wider set of inputs than a strict type would allow. An inspection that treats the annotation as a rigid type produces false positives on correct code, which is the reason people turn inspections off.

The plugin also handles the parts of pydantic's type syntax that the language does not know about. Support for typing.Annotated from PEP 593 is listed, and regex arguments in Field and constr are treated as Python regex string literals, so the pattern is understood as a pattern rather than as an opaque string.

The result is an IDE that can both complete and complain about pydantic code, which is the combination that makes a plugin worth installing. An inspection that only adds errors, or only adds completion, is much easier to live with but much less useful.

Validators, config and the frozen flag

Validator support is the other half of the model awareness, and the details listed are the ones that actually come up in a pydantic codebase.

For validator and field_validator, the plugin respects that the first argument of the method is cls, it provides auto-completion for the field name arguments of validator and field_validator, and it associates a validator with the field it validates. That association is what enables refactoring and jumping, and it means a field rename can be checked against the validator arguments, with the field name validated on validator arguments.

Config and ConfigDict support covers the configuration objects of a model. There is auto-completion for Config and ConfigDict, and the plugin reads model configuration such as frozen=True, which means a model that pydantic will refuse to mutate after construction is understood as such by the IDE.

The frozen case is a good illustration of why a dedicated plugin exists. A model declared frozen is immutable at runtime, and an IDE that knows it can flag an assignment that would fail at runtime. A general Python analyser sees an ordinary class attribute and says nothing.

GenericModel, dataclasses, SQLModel and the experimental create_model

The plugin does not stop at BaseModel, and the supported variants come with version requirements attached, which is a useful way to read the plugin's history.

GenericModel support carries the same feature set as BaseModel, and it needs plugin version 0.3.1 or later. The dataclass support, for pydantic.dataclasses.dataclass, needs PyCharm 2020.2 together with plugin 0.1.0, because from that PyCharm version the IDE treats pydantic dataclasses as third-party dataclasses and the plugin adds the model-aware behaviour on top. SQLModel gets the same features as BaseModel from plugin 0.3.12 or later.

The one that is flagged differently is pydantic.create_model, which is marked experimental. The support there is described as the minimum features for a model created by create_model, and the reason is obvious from the mechanism: create_model builds a class at runtime from arguments, so there is no class definition for the plugin to read when the file is indexed. Anything that has to be inferred from a static class body is simply not there to be inferred.

The supported pydantic major versions are listed as v0, v1 and v2, so the plugin has followed pydantic through its breaking change rather than staying on one generation.

Installing from the Marketplace, on PyCharm 2020.2 or later

The install path is the ordinary one for a JetBrains plugin. The plugin is in the JetBrains repository and has a page on the Marketplace, and you install the stable version from PyCharm's own Marketplace, under Preferences and then Plugins and then Marketplace, following the official JetBrains documentation on managing plugins.

The one requirement is stated in bold in the README: the plugin requires PyCharm 2020.2 or later, and the parenthetical note that this includes other JetBrains IDEs is worth reading, because the plugin is not PyCharm exclusive even though it is a Python plugin.

If you are not using a plugin marketplace, the repository itself is a Gradle project, with a build.gradle.kts, a settings.gradle.kts, a gradle wrapper, a resources directory, a testData directory and a testSrc directory for the plugin's own tests, plus a scripts directory and a qodana configuration. The documentation site is built with mkdocs and a pinned theme package, both listed in a requirements file, and the mkdocs.yml at the root drives it.

The documentation site lives at koxudaxi.github.io/pydantic-pycharm-plugin, and the README notes that the project is currently in an experimental phase.

Maintenance, licensing and the shape of the project

The release history shows a project on a steady patch cadence. The recent versions are 0.4.29 from 2026-08-12, 0.4.28 from 2026-07-29 and 0.4.27 from 2026-07-23, and the last push to the repository was on 2026-10-12, with the repository not archived. The version number is still in the zero range, which is consistent with the README's own statement that the project is in an experimental phase, even though the feature set is substantial and the marketplace rating badge is in the README.

The licence is MIT, with the LICENSE file at the root, and there is a second file, LICENSE_apache_version_2.txt, alongside a NOTICE.txt. The presence of an Apache 2.0 licence text in the repository usually means some part of the codebase or its resources is under that licence, which is worth checking against the NOTICE file rather than assuming the whole plugin is under the MIT terms stated in the README.

The author is also the author of a Poetry plugin for PyCharm, and the motivation link points back to the original pydantic issue, so the scope has stayed narrow and tied to a real upstream gap. The repository also carries a CHANGELOG.md, and the JetBrains plugin page is the authoritative distribution point.

Editorial conclusion

The plugin fits a Python team on PyCharm that uses pydantic models heavily and is tired of the IDE reporting a BaseModel constructor as taking no arguments, since the features that matter are constructor signatures, field refactoring and a type inspection that understands pydantic. It does not fit a team on another IDE, and create_model support is explicitly experimental. Before you install it, check three things: that your PyCharm is 2020.2 or later, which the plugin requires, that the pydantic major version in your project is v0, v1 or v2, all of which the plugin supports, and that your model style is covered, because SQLModel support needs plugin 0.3.12 or later and the dataclass support needs plugin 0.1.0 with PyCharm 2020.2. The plugin is MIT licensed, the current version is 0.4.29 from 2026-08-12, and the last push was on 2026-10-12.

Frequently asked questions

Official sources

1. koxudaxi/pydantic-pycharm-plugin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases