`--disable-error-code=unused-ignore` should override `enable_error_code = ["unused-ignore"]`
Bug Report
mypy bug.py --disable-error-code=unused-ignore shows
bug.py:1: error: Unused "type: ignore" comment [unused-ignore] Found 1 error in 1 file (checked 1 source file)
To Reproduce
bug.py
a = 1 # type:ignore[comparison-overlap]
pyproject.toml
[tool.mypy]
enable_error_code = ["unused-ignore"]
Expected Behavior
No error. IMHO, command-line settings should override settings file.
Actual Behavior
See above
Your Environment
- Mypy version used: 1.19.0
- Mypy command-line flags: see above
- Mypy configuration options from
mypy.ini(and other config files): see above - Python version used: 3.14.0
Yep, https://mypy.readthedocs.io/en/stable/config_file.html#config-file-format ("When options conflict, the precedence order...") specifies that command line options should overrule top-level configuration file options. I haven't looked into this further.
Confirmed. It is common knowledge that CLI flags override envvars, and those in turn override configuration file entries (local, then user-level, then global).
This is not specific to --{en,dis}able-error-code, possibly-undefined suffers from the same problem:
$ mypy -c $'if 1:a = 1\nprint(a)' --cache-dir=/dev/null
Success: no issues found in 1 source file
$ cat <<EOF >pyproject.toml
[tool.mypy]
enable_error_code = ["possibly-undefined"]
EOF
$ mypy -c $'if 1:a = 1\nprint(a)' --cache-dir=/dev/null
<string>:2: error: Name "a" may be undefined [possibly-undefined]
Found 1 error in 1 file (checked 1 source file)
$ mypy -c $'if 1:a = 1\nprint(a)' --disable-error-code=possibly-undefined --cache-dir=/dev/null
<string>:2: error: Name "a" may be undefined [possibly-undefined]
Found 1 error in 1 file (checked 1 source file)
Probably all codes that are disabled by default are affected.
The ultimate issue is that enable-error-code has lower priority than disable-error-code, so two strategies clash: --disable-error-code should have higher priority because it is passed as argv, but lower priority because we declare so:
Note: This flag will override disabled error codes from the --disable-error-code flag.
So if both were provided by the same means (both as CLI flags or both as config file entries), this behaviour would be sound, but not when the priority is clear from the source.
Hi! I’m a first-time contributor and I’d like to work on fixing this issue. Would adjusting the precedence logic in the CLI/config parser and adding tests to ensure that command-line flags correctly override configuration be an okay approach for me to take on?
@franzengel04 thanks! Yes, that sounds good to me:)