Skip to content

Current best practices for combining pydantic & mypy #995

@DBCerigo

Description

@DBCerigo

Part 1: there seems to be an inconsistency between the conclusion from this issue #245 being "Solution here is to use dataclasses which I think mypy should work with properly.", and then this pydantic docs page https://pydantic-docs.helpmanual.io/usage/mypy/
Is the conclusion of that issue now defunct, and inheriting from BaseModel is supposed to work correctly with mypy, or are the docs incorrect? I raise this as in our current usage of BaseModel we get the ("mypy not working") behaviour from #245 and not the ("mypy working") behaviour from docs.

Part 2: given we really like pydantic (a thanks and congrats to all contributors to it!), what is currently advised by core pydantic devs as the best practice to use pydantic while still get type-checking with mypy. The options I found are:
a. Use pydantic.dataclasses as per https://pydantic-docs.helpmanual.io/usage/dataclasses/#nested-dataclasses
b. Use the pydantic.mypy plugin* as per https://pydantic-docs.helpmanual.io/mypy_plugin/
The hope with this question is that it can provide advice to others out there looking to combine mypy & pydantic on how best to do so currently 😸

Other refs for mypy + pydantic usage: #366 #957 #156 #238

*Note, in this same docs page it states that mypy works with pydantic (assuming implying with BaseModel also) out of the box, which is again not what #245 concludes 😬

(I personally think mypy is pretty 👎, so I appreciate the presumed headache it causes you all too, but that optional type-hinting in general is very 👍)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions