Repository navigation
Subclass method parameter names are not checked against superclass #6709
Description
- Are you reporting a bug, or opening a feature request?
Bug
- Please insert below the code you are checking with mypy,
or a mock-up repro if the source is private. We would appreciate
if you try to simplify your case to a minimal repro.
When a subclass renames the parameters of a method, this results in runtime errors; but this seems like something that should be statically detectable.
The below code provides a superclass A, and two similar subclasses B and C that differ in that C renames the parameter to the method f, but B does not.
mypy vs runtime behaviour for variables c and c2 seems inconsistent, while for c3 and c4 it seems ok.
I was expecting some mypy error to be raised when defining f in class C.
class A:
def f(self, x: int) -> None:
print("A: ", x)
class B(A):
def f(self, x: int) -> None:
print("B: ", x)
class C(A):
def f(self, n: int) -> None:
print("C: ", n)
a = A()
a.f(x=3)
b = B() # type: A
b.f(x=3)
c = C() # type: A
c.f(x=3) # mypy passes, but gives runtime error: TypeError: f() got an unexpected keyword argument 'x'
c2 = C() # type: A
c2.f(n=3) # mypy gives an error: error: Unexpected keyword argument "n" for "f" of "A" but runtime works.
c3 = C() # type: C
c3.f(x=3) # mypy give type error: error: Unexpected keyword argument "x" for "f" of "C", and runtime error: mypy-issue.py:25: error: Unexpected keyword argument "x" for "f" of "C"
c4 = C() # type: C
c4.f(n=3) # no errors in mypy or at runtime
- What are the versions of mypy and Python you are using?
$ mypy --version
mypy 0.670
$ python --version
Python 3.7.2+
- Do you see the same issue after installing mypy from Git master?
yes - mypy 0.710+dev.f10528a5a8d9e98939ceb84d40e614d1f159d9a0
- What are the mypy flags you are using? (For example --strict-optional)
With no flags, and with --strict.
Activity
gvanrossum commentedon Apr 22, 2019
This is actually done intentionally because for calls with positional parameters the argument name is irrelevant. If we were to change this behavior a lot of code that works and is considered correct in practice would be found out of compliance.
However I could see us accepting a PR that adds a flag that makes this behavior more strict, and adds that flag to the set of flags turned on by
--strict.wkschwartz commentedon Sep 10, 2019
It seems that Mypy does actually check parameter names if
**kwargsis part of the signature. The following Python file has the output below (on Python 3.7.3, Mypy 0.720 under the default configuration). Notice changing the name of the parameter fromxton, and adding**kwargsarguments.Output:
B.fis compatible withA.fbutC.fis not compatible withD.f. Adding**kwargsmade Mypy decide that changing the parameter name fromxtonwas bad.If nothing else, this error is very difficult to understand. However, I agree with #6709 (comment) and think that logic applies even when there are
**kwargs: the absence of**kwawrgsin no way indicates that client code will call the function only with positional arguments.JukkaL commentedon Sep 11, 2019
One major problem with checking argument names is that typeshed stubs may have dummy argument names in methods. Some of the argument names are probably just incorrect, while others should be positional-only. For example, many methods implemented in C should have positional-only arguments to facilitate precise checking of argument names. I'm not sure how useful strict checking of argument names would be if we don't improve typeshed first.
antoniogamizdelgado commentedon Feb 1, 2023
Any updates on this? I think the idea of having a flag to allow this for those users that need it is fine. For those cases where this flag mayb create some problems it can be deactivated (which would be its default value I suppose).
AlexWaygood commentedon Aug 13, 2026
FWIW I would wager that nearly all typeshed's parameter names are correct now, because we've improved stubtest a lot since 2019 and we've also ratcheted up the strictness of our stubtest settings in typeshed.
hauntsaninja commentedon Aug 14, 2026
stubtest didn't really exist in 2019, so we've definitely improved it since then!
However, the PR to enable this check is truly awful on primer #18355 so when we do this it will need to be opt-in