You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Permit configuration via a stand-alone TOML file (mypy.toml) #18617
In #5205, MyPy gained support for declaring configuration in the TOML format, but only in pyproject.toml. I propose supporting configuration via a stand-alone TOML document, such as mypy.toml or .mypy.toml.
Pitch
This parallels, and perhaps would eventually replace, configuration via mypy.ini. This is most useful when checking non-project code, such as in Python (python/cpython#129708), where we have several distinct mypy.ini files to support type-checking different directories of a larger project. It may be useful for mono-repo layouts, where again the use of pyproject.toml is undesirable. Finally, this would be useful to keep tool configuration to independent files — in the Sphinx project, there are several hundred lines of mypy configuration in pyproject.toml, dominating the content of the file.
The .ini format also has its limitations. Like not supporting comments at the end of a line and a weird exclude.
Additional benefits includes: a single toml formatter (rather than needing an ini formatter just for this config). And IntelliSense could be provided through a schema.
[[mypy.overrides]] sections with long module = [...] lists are painful to migrate to mypy.ini which requires stuffing what were nicely formatted, multi-line lists into a long, comma-separated messes.
Personally I'm not enthusiastic about adding yet another configuration file. Having more configuration files means the config system is more complex to understand as users need to think about the precedence between all these different files.
I don't really see a reason for mypy.ini and mypy.toml to coexist in the same folder.
If multiple non-pyproject mypy config files are detected, I don't mind erroring out and sidestepping the precedence issue entirely.
I personally do prefer mypy's toml configuration format. But I'm still using mypy.ini instead of pyproject.toml because I don't like shoving all tooling config in a single file. Makes it much harder to template/cookie-cutter. Or find from an ide file search.
Reacted by Edgar Ramírez Mondragón and Adam Turner
Activity
Avasam commentedon Feb 19, 2025
The
.iniformat also has its limitations. Like not supporting comments at the end of a line and a weird exclude.Additional benefits includes: a single
tomlformatter (rather than needing aniniformatter just for this config). And IntelliSense could be provided through a schema.michael-pplx commentedon Sep 10, 2025
[[mypy.overrides]]sections with longmodule = [...]lists are painful to migrate tomypy.iniwhich requires stuffing what were nicely formatted, multi-line lists into a long, comma-separated messes.michael-pplx commentedon Sep 10, 2025
Note that explicitly calling
mypy --config-file=.mypy.tomldoes workofek commentedon Nov 11, 2025
I would really love this capability, especially the
.mypy.tomlvariant.edgarrmondragon commentedon Apr 21, 2026
There's a PR which seems to be in a good state:
mypy.tomland.mypy.tomlconfiguration files #21019I'm curious what the maintainers think of this feature request.
JelleZijlstra commentedon Apr 22, 2026
Personally I'm not enthusiastic about adding yet another configuration file. Having more configuration files means the config system is more complex to understand as users need to think about the precedence between all these different files.
Avasam commentedon Apr 22, 2026
I don't really see a reason for mypy.ini and mypy.toml to coexist in the same folder.
If multiple non-pyproject mypy config files are detected, I don't mind erroring out and sidestepping the precedence issue entirely.
I personally do prefer mypy's toml configuration format. But I'm still using mypy.ini instead of pyproject.toml because I don't like shoving all tooling config in a single file. Makes it much harder to template/cookie-cutter. Or find from an ide file search.