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
Mypy doesn't catch renaming arguments in overrides #19132
When overriding methods in subclasses, it's important to keep the same argument names since any argument in Python can be given as a keyword argument. If an override in a subclass changes the name of a parameter, it breaks the polymorphism for any user of the class using keyword arguments
The code example above should not type check, as OtherAdder is not a valid subclass of Adder. If I type check this code in pyright, it correctly identifies this issue:
$ pyright classes.py
/path/to/classes.py
/path/to/classes.py:16:9 - error: Method "add" overrides class "Adder" in an incompatible manner
Parameter 3 name mismatch: base parameter is named "b", override parameter is named "new_b" (reportIncompatibleMethodOverride)
1 error, 0 warnings, 0 informations
Actual Behavior
Mypy lets this error through:
$ mypy classes.py
Success: no issues found in 1 source file
Your Environment
Mypy version used: mypy 1.15.0 (compiled: yes)
Mypy command-line flags: None
Mypy configuration options from mypy.ini (and other config files): None
Given #1013, seems like mypy intentionally does not want to do that globally. Personally I'd prefer this implemented as a separate strictness flag - some projects may prefer to opt out, but IMO most of the projects should be enforcing same argument names consistently. This is an immediate dupe of #8314 which was closed as a dupe of #1013, so let's keep tracking this feature there.
Activity
sterliakov commentedon May 22, 2025
Given #1013, seems like mypy intentionally does not want to do that globally. Personally I'd prefer this implemented as a separate strictness flag - some projects may prefer to opt out, but IMO most of the projects should be enforcing same argument names consistently. This is an immediate dupe of #8314 which was closed as a dupe of #1013, so let's keep tracking this feature there.