-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Check if decorator returns use keyword (unexpected-keyword-arg
)
#5547
Check if decorator returns use keyword (unexpected-keyword-arg
)
#5547
Conversation
Pull Request Test Coverage Report for Build 1594454584
💛 - Coveralls |
Blocked by #5549. Rest of the tests and coverage look good so this is ready for review. |
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.
It's heart-warming to see really old issues getting addressed 🎉
@@ -0,0 +1,118 @@ | |||
"""Tests for unexpected-keyword-arg""" |
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.
The tests are on point !
|
||
# If we can't infer the decorator we assume it satisfies consumes | ||
# the keyword, so we don't raise false positives | ||
if not inferred: |
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.
Not really related to this MR but if we have to handle confidence level, this kind of return where we do not exactly know if inference was used or not in the calling code will be a headache later. Makes me thing that implementing confidence properly will be an enormous work, maybe not even worth it.
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.
Thankfully we have UNDEFINED
😄
@DanielNoord maybe I should open a new ticket, but just tried this out with the latest version of the def example_decorator(*new_func_args, **new_func_kwargs):
def decorator(func):
def wrapper(*args, **kwargs):
print_me = kwargs.pop("print_me", None)
def inner(*inner_args, **inner_kwargs):
print(print_me)
return func(*inner_args, **inner_kwargs)
return inner(*args, **kwargs)
return wrapper
if len(new_func_args) == 1 and len(new_func_kwargs) == 0 and callable(new_func_args[0]):
return decorator(new_func_args[0])
return decorator
@example_decorator
def example_func(num):
return num ** 2
example_func(6, print_me="hello") (Note that no error is raised by pylint if we remove the top-level function ( Using pylint on commit hash e75e37a, this is the error that's printed out:
Calling
|
Ah yes, this won't be catched. Not sure how easy it would be to implement looking for inner return values. |
Sorry for taking forever, but finally opened the ticket :) |
Thanks @martimlobao! Totally forgot about this myself. |
lol sorry for the ridiculously incomplete title, i started writing it and then forgot to finish 🤦♂️ |
doc/whatsnew/<current release.rst>
.Type of Changes
Description
Closes #258 (🎉)
I'd like to see the coverage report on this. I might need to add some additional tests.