A simplification of some old code I am trying to add mypy to:
class Base(object):
def foo(self):
# type: () -> None
a = self.static_foo()
class SubClass(Base):
static_foo = staticmethod(lambda: 5)
Results in the error:
error: Incompatible types in assignment (expression has type "staticmethod", base class "Job" defined the type as "Callable[[], int]")
Oddly, as far as I can tell, static_foo is not actually defined on the base class.
This is using Dropbox's mypy setup, with --strict-optional. I am actually not sure which version we're on, but can look it up and edit this issue.
_.py:16: error: Incompatible types in assignment (expression has type "staticmethod", base class "Base" defined the type as "Callable[[], int]")
Now it's very clear that the error is caused by mypy's lack of understanding of how staticmethod() relates to @staticmethod.
As to why it gave this same error for you with the real version of the original code, even though there was no definition of static_foo in the base class there, I'm still not sure. But maybe you don't care and you would just like mypy's understanding of staticmethod() to be improved?
Improving mypy's understanding of inline usage of staticmethod seems tractable/higher priority. Given how clever this code is, someone may have monkey patched something somewhere to the same effect of the minimal example.
Hah! This bug was never fixed. The reason I thought it was is because I was testing on 3.10, and the typeshed stub (correctly) states that staticmethod.__call__ was added in 3.10. This means that there's no false positive error on 3.10, but it's not because the mypy bug is fixed, it's because the typeshed stub is different if you're running on 3.10.
Activity
gvanrossum commented on Feb 14, 2018
There must be a little more going on than you show, since if I type that example into mypy:
I get a much simpler error:
momandine commented on Feb 14, 2018
Well, this example doesn't error at all, which is closer:
momandine commented on Feb 14, 2018
This does repro (though in my actual example, there is no staticmethod declared on the base class (???).
momandine commented on Feb 14, 2018
More minimal repro:
gvanrossum commented on Feb 14, 2018
And to clarify, this gives the following error:
Now it's very clear that the error is caused by mypy's lack of understanding of how staticmethod() relates to @staticmethod.
As to why it gave this same error for you with the real version of the original code, even though there was no definition of static_foo in the base class there, I'm still not sure. But maybe you don't care and you would just like mypy's understanding of staticmethod() to be improved?
momandine commented on Feb 15, 2018
Improving mypy's understanding of inline usage of staticmethod seems tractable/higher priority. Given how clever this code is, someone may have monkey patched something somewhere to the same effect of the minimal example.
AlexWaygood commented on Mar 28, 2022
The false-positive error is no longer emitted on mypy 0.930+.
youtux commented on May 4, 2022
@AlexWaygood this is error is back, at least with mypy 0.950 and 3.7 <= python <= 3.9:
https://mypy-play.net/?mypy=0.950&python=3.8&gist=1e25a16047bae31555e210da7797f640
AlexWaygood commented on May 4, 2022
Hah! This bug was never fixed. The reason I thought it was is because I was testing on 3.10, and the typeshed stub (correctly) states that staticmethod.__call__ was added in 3.10. This means that there's no false positive error on 3.10, but it's not because the mypy bug is fixed, it's because the typeshed stub is different if you're running on 3.10.
AlexWaygood commented on May 4, 2022
Thanks @youtux :)
R Add type annotations
R Add type annotations
Ignore check for staticmethods in transforms because of python/mypy#4574
Add mypy to CI (#606)
emmatyping commented on Dec 27, 2024
3.9, the last version affected by this bug, has 8 more months before it hits EOL. I don't think it is worth fixing this.