-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Enhanced support for @Property decorator in pyreverse #10057
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
Conversation
This comment has been minimized.
This comment has been minimized.
a380c46
to
a707767
Compare
This comment has been minimized.
This comment has been minimized.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10057 +/- ##
=======================================
Coverage 95.86% 95.86%
=======================================
Files 175 175
Lines 19069 19072 +3
=======================================
+ Hits 18281 18284 +3
Misses 788 788
🚀 New features to boost your workflow:
|
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉 This comment was generated for commit 8ff2fdd |
@Pierre-Sassoulas I cleaned up my previous solution and have it actually working, when there is a property that has a return type annotated. However if there is no return type annotated it does not work, so the current test structure in |
) and decorated_with_property(associated_nodes): | ||
if associated_nodes.returns: | ||
type_annotation = get_annotation_label(associated_nodes.returns) | ||
node_name = f"{node_name} : {type_annotation}" |
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.
I am not that experienced, but do you think it is possible to infer the return type using astroid in case the property is not annotated? In essence add an else branch in here
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.
In pylint we infer only and do not trust the typing (because there was no typing when pylint was created), so yes. Not sure what the philosophy in pyreverse should be. Probably that trusting the typing first then inferring makes sense (even if changing the philosophy in pylint would be humongous work and probably make pylint inconsistent).
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.
I think this philosophy makes sense. Also assumed that pylint works that way, this is why I tried to come up with a solution using node.infer_call_result()
however I always got UNINFERABLE
. Probalby it is an error on my side, because I have not that much experience with astroid :)
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.
I'm not surprised you're getting uninferable, property inferring in pylint is not very good. Making property inference in astroid better would help in both pyreverse and pylint but no one worked on it as of today.
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.
Makes a lot of sense. So I guess for now relying on the annotations for the Properties is fine. Unfortunately I currently dont have the time to work on that myself. Maybe something to work on in a follow up PR
I guess we could fix coverage by annotating the the properties under |
You can try using the functional tests for They are picked up automatically, and the output generated by |
Thats nice, I did not know that, Then I will use this for testing :) |
I think the pypy error is not related to my changes |
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.
I feel like putting both functional tests (annotated and not annotated) into a single file fits more with the current 'one functional test file per feature/behavior', but that is personal preference. 🙂 Otherwise looks good, thanks for the fix. Let's see if adding a newsfragment also fixes the PyPy problem, as simply re-running the job did not help.
Added a newsfragment and merged it into 1 file. Pypy action is still failing though |
Don't bother with pypi3.10 it's failing on main too :) |
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.
Thanks again for fixing this issue!
Type of Changes
Description
Closes #9212
Closes #7644
Fixed by properly extracting the return types when handling class attributes. Implementation is much cleaner than before.