-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Move self argument checks to a later phase - after decorator application, if any #19490
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
Move self argument checks to a later phase - after decorator application, if any #19490
Conversation
Surprisingly there are a few more more related tickets, I'll go through them tomorrow. |
This comment has been minimized.
This comment has been minimized.
This is working towards a much-needed QOL change IMO - thank you. But thinking about this problem - is some of the self-check procedure itself redundant? Given this example: class A:
def method() -> None: ... # self-check error
def method2(arg: str, /) -> None: ... # self-check error
# mypy already picks these up; are the self-check errors above redundant?
A().method() # Attribute function "method" with type "Callable[[], None]" does not accept self argument [misc]
A().method2() # Invalid self argument "A" to attribute function "method2" with type "Callable[[str], None]" Removing part of the self-check would naturally allow descriptor method transforms (and thus solve the original issue). It would also allow skipping the typing ceremony in several cases, such as omitting (Of course, an unannotated first positional argument is still implicitly |
@bzoracler For me current behaviour (errors at the definition site) is superior by a huge margin. Tracing selftypes across modules is inconvenient, I really want mypy to say "hey, you're probably missing I know one and only one use case where this is still a problem (one-time decorators you mentioned). I don't really like when people do that, it takes a few more more seconds to parse in my head, but it's a common pattern that has some merit. We can make that an exception as well: do not emit these errors if func is later used as a decorator in the same class.
Could you elaborate? |
Forget the mention of Thinking about it a bit more, several other popular languages (C++, Java) don't use explicit |
|
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG, this makes sense! I have few suggestions for extra tests.
This comment has been minimized.
This comment has been minimized.
@sterliakov The new |
Ough. Thanks! I decided to go with slightly different logic - only silence inside untyped function (same as |
Diff from mypy_primer, showing the effect of this PR on open source code: zope.interface (https://github.com/zopefoundation/zope.interface)
- src/zope/interface/common/numbers.py:42: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
- src/zope/interface/common/numbers.py:52: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
- src/zope/interface/common/collections.py:119: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
- src/zope/interface/common/collections.py:134: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
- src/zope/interface/common/collections.py:174: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
- src/zope/interface/common/collections.py:182: error: Method must have at least one argument. Did you forget the "self" argument? [misc]
|
Fixes #19392.
Fixes #18989.
Fixes #18720.
Fixes #13434 (correct support for
staticmethod
wrappers, but not for equivalentclassmethod
s reported in #18968).Deferring this check in presence of decorators allows decorators that perform non-trivial transformations (such as making methods from non-methods and vice versa).