-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to assign a function a method #2427
Comments
I swear, this is a duplicate, but I can't find the issue # yet... |
@kirbyfan64 Yeah...I poked around and couldn't find anything. Happy to close this if it is! |
I think @sixolet might be interesting in this... |
The mypy callable type representation isn't expressive enough to to check assignments to methods precisely. In particular, at least bound methods and unbound function objects should be treated differently. Consider this example: class A:
def f(self): pass
def g(self): pass
def h(self): pass
A.f = h # rvalue has one argument (unbound)
A().f() # okay
A.f = A().g # rvalue has no arguments (bound)
A().f() # okay When we have value with an annotated callable type, such as I'm pretty sure this is already broken in other contexts, but we may want to resolve this eventually. Some random ideas:
Option (3) doesn't seem worth the added complexity, to be honest, as it's always possible to fall back to |
So is the problem that when we see class C:
f = None # type: Callable[[int, int], int] we don't know whether that defines an instance variable or a class variable? Maybe we can use class C:
f = None # type: ClassVar[Callable[[int, int], int]] and if ClassVar is not used assume Of course initializations inside I do think mypy ought to be fully aware of bound and unbound methods. But perhaps the original problem is due to something else? The immediate problem seems to be that we don't try to match |
Isn't this a duplicate of #708? But maybe it makes sense to keep this open, since this issue contains some additional discussion. |
Not really -- IIUC this seems about monkey-patching a class, whereas #708 is about assigning to function attributes. |
A case where I keep running into that issue is when writing unit tests and trying to replace methods with Typically, class It does feel bad to add a bunch a |
I prefer |
What's the state of this (about monkey patching a method)? It seems like it needed discussion, has that happened offline? |
The has been no progress recently. The workarounds discussed above ( |
Cool, thanks for the update. 5:) |
This is caused because of mypy's issue sanic-org#2427 python/mypy#2427
I think that I am running into this. The code that causes the mypy error is |
Hi, any progress on this? |
In my case I'm not even monkey-patching (at least, I don't feel like it is), I'm trying to take a function as a parameter of init and use it as a wrapper. Like this (note simplified example, so it might not make entire sense):
If I remove |
It might silence mypy, but it's one of flakeheaven's bugbears.
So I still prefer to use |
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
ignore method assignment. Currently mypy cannot check this. Related upstream issues: - python/mypy#2427 - python/mypy#708
mypy doesn't appear to have a better way to handle this. python/mypy#2427 Convert method assignments to Mock usages were possible.
Fixes #2427 I also add some special logic, so that `# type: ignore[assignment]` will cover `[method-assign]`.
For posterity, after some offline discussions we agreed that it would be hard to find semantics here that would satisfy everyone, and instead there will be a dedicated error code for this case. If you don't want mypy to complain about assignments to methods, use |
python/mypy#2427 (comment) describes the mypy change, in mypy 1.1.0
python/mypy#2427 (comment) describes the mypy change, in mypy 1.1.0
For example:
Results:
This assignment should be legal as any call to
get_x
will be able to callget_x_patch
. It looks like 3ce8d6a explicitly disallowed all method assignments, but there's not a ton of context behind it.I know monkeypatching is generally frowned upon, but is unfortunately a very popular part of Python. I can always mark those lines as ignored, but I'd rather be able to test that the patch is compatible with the underlying method with mypy.
The text was updated successfully, but these errors were encountered: