-
Notifications
You must be signed in to change notification settings - Fork 116
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
Ruff linter #586
Ruff linter #586
Conversation
I made similar changes as in pymc-devs/pymc#7091 . Let's have an initial feedback round 😄 ! |
7f55843
to
0f37dda
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #586 +/- ##
==========================================
- Coverage 80.92% 80.92% -0.01%
==========================================
Files 162 162
Lines 46641 46627 -14
Branches 11399 11399
==========================================
- Hits 37746 37732 -14
Misses 6667 6667
Partials 2228 2228
|
Co-authored-by: Ben Mares <services-git-throwaway1@tensorial.com>
To fix |
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 is fine since one rarely overrides builtins, although I'll occasionally do something like
class SpecialString(str):
"""Special instance of str for type hints"""
It may be nice to get another opinion though, e.g. from @ricardoV94.
if type(condition[1]) is list: | ||
if isinstance(condition[1], list): |
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.
Was this change automatic or by hand? I think this is safe, but strictly speaking condition[1]
could theoretically be a subclass of list
(although subclassing builtin types is generally pretty broken, so nobody should ever do it). The reason I bring it up is because we're a bit stalled on #581 due to similar issues. This PR will make that obsolete, but I'm curious if you have any thoughts.
if type(condition[1]) is list: | ||
if isinstance(condition[1], list): |
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.
Same as above
assert type(storage_map_list[0]) is list | ||
assert type(compute_map_list[0]) is list | ||
assert isinstance(storage_map_list[0], list) | ||
assert isinstance(compute_map_list[0], list) |
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.
Same comment
if type(profile) is not bool and profile: | ||
if (not isinstance(profile, bool)) and profile: |
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.
Same
if type(condition[1]) is list: | ||
if isinstance(condition[1], list): |
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.
Same
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.
All of them were made manually by me as ruff raised an error and suggested this solution 😬.
I'm concerned that ruff isn't picking up these pyupgrade fixes: 4c417cc Note that those were engaged after upgrading |
The Either way, these look okay. Just wanted to know because of the discussion in the other PR |
The precent format is used widely in the C code generation with |
I changed the defauldict and deque changes manually 🙈. Ruff just raised the errors. What should I fix ? |
Those are fine. The question is whether you changed the |
Yes, I did! It was manual work case by case 🙈 |
The this is the only thing we should check. Looks good otherwise |
There are many 😄. I would rather create an subsequent issue... What do you think ? |
This PR already has 70 changed files, and that makes it really difficult to view what's going on with the config. In an ideal world I think we'd break this up into one PR that does all the formatting changes (assuming they're compatible with both flake8 and ruff). Then there would be a subsequent clean PR that's config-only, but maybe by necessity contains code changes that are not cross-compatible. That would probably be a bit overkill with too much work, but I do like the idea of smaller PRs. |
Yeah, this PR escalated super fast 🫠🙈. If you all want we can close this one and start step by step as suggested. |
Hm, I'm in favor of sticking with this one. Do we really need to thoroughly go through every line change? I think a spot change is enough, we have unit-tests and a high level of confidence its doing the right thing. |
Shall we merge and open issues for the % format and the pyugrade question then? |
Need to sort the conflicts with the PR we just merged! |
Easy, it's just spacing issues. Done. |
🙌💪🙏 |
I opened #597 for the Who would like to take care of the |
If there is no expected “deadline” I can take it and work on it bit by bit 🐢 |
Thanks @juanitorduz!!! Indeed this seems pretty low-priority to me. But would you like to open an issue so that we have a record of the todo? |
I'll do so once I'm on a proper pc (👶 at the moment 😅) |
Issue created: #601 |
Continuation of an apparently stale PR #539