Skip to content
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

Merged
merged 12 commits into from Jan 15, 2024
Merged

Ruff linter #586

merged 12 commits into from Jan 15, 2024

Conversation

juanitorduz
Copy link
Contributor

Continuation of an apparently stale PR #539

@juanitorduz juanitorduz marked this pull request as draft January 11, 2024 20:47
@juanitorduz juanitorduz self-assigned this Jan 11, 2024
@juanitorduz juanitorduz marked this pull request as ready for review January 11, 2024 21:25
@juanitorduz
Copy link
Contributor Author

I made similar changes as in pymc-devs/pymc#7091 .

Let's have an initial feedback round 😄 !

@codecov-commenter
Copy link

codecov-commenter commented Jan 11, 2024

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (c5b96d9) 80.92% compared to head (be86730) 80.92%.
Report is 2 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            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              
Files Coverage Δ
pytensor/compile/debugmode.py 61.46% <100.00%> (ø)
pytensor/graph/basic.py 89.08% <100.00%> (ø)
pytensor/graph/destroyhandler.py 68.98% <100.00%> (ø)
pytensor/graph/fg.py 89.08% <100.00%> (-0.04%) ⬇️
pytensor/graph/rewriting/basic.py 73.04% <100.00%> (-0.02%) ⬇️
pytensor/link/c/basic.py 87.61% <100.00%> (ø)
pytensor/link/c/cmodule.py 55.74% <ø> (ø)
pytensor/link/c/params_type.py 80.41% <ø> (ø)
pytensor/link/c/type.py 75.98% <100.00%> (ø)
pytensor/link/jax/dispatch/elemwise.py 81.69% <ø> (ø)
... and 31 more

... and 1 file with indirect coverage changes

pyproject.toml Outdated Show resolved Hide resolved
juanitorduz and others added 2 commits January 12, 2024 08:23
Co-authored-by: Ben Mares <services-git-throwaway1@tensorial.com>
@juanitorduz
Copy link
Contributor Author

juanitorduz commented Jan 12, 2024

To fix pyupgrade I had to skip UP031: Use format specifiers instead of percent format because otherwise, we have Found 135 errors which I suggest not to fix on this PR and instead create an issue about it. I do not understand why the previous pre-commit did not catch this 🤔.

Copy link
Contributor

@maresb maresb left a 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.

Comment on lines -864 to +866
if type(condition[1]) is list:
if isinstance(condition[1], list):
Copy link
Contributor

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.

Comment on lines -904 to +906
if type(condition[1]) is list:
if isinstance(condition[1], list):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

Comment on lines -1075 to +1076
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)
Copy link
Contributor

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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

Comment on lines -2135 to +2143
if type(condition[1]) is list:
if isinstance(condition[1], list):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

Copy link
Contributor Author

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 😬.

@maresb
Copy link
Contributor

maresb commented Jan 14, 2024

I'm concerned that ruff isn't picking up these pyupgrade fixes: 4c417cc

Note that those were engaged after upgrading pyupgrade from 3.3.1 to 3.15.0.

@ricardoV94
Copy link
Member

The isinstance checks seem good, since they are all about built-in types. I'm glad it didn't try to override the type(...) == type(...) with custom types that @maresb mentioned. Is the auto-linter more restricted, or where these changes you did manually @juanitorduz?

Either way, these look okay. Just wanted to know because of the discussion in the other PR

@ricardoV94
Copy link
Member

To fix pyupgrade I had to skip UP031: Use format specifiers instead of percent format because otherwise, we have Found 135 errors which I suggest not to fix on this PR and instead create an issue about it. I do not understand why the previous pre-commit did not catch this 🤔.

The precent format is used widely in the C code generation with % locals. That will take some work to refactor so definitely fine to ignore. Would be nice if we could ignore per-file if that's not too many?

@juanitorduz
Copy link
Contributor Author

juanitorduz commented Jan 14, 2024

I changed the defauldict and deque changes manually 🙈. Ruff just raised the errors. What should I fix ?

@maresb maresb mentioned this pull request Jan 14, 2024
6 tasks
@ricardoV94
Copy link
Member

ricardoV94 commented Jan 14, 2024

I changed the defauldict and deque changes manually 🙈. Ruff just gce me the errors. What should I fix ?

Those are fine. The question is whether you changed the type(x) == y to isinstance(x, y) manually?

@juanitorduz
Copy link
Contributor Author

Yes, I did! It was manual work case by case 🙈

@ricardoV94
Copy link
Member

I'm concerned that ruff isn't picking up these pyupgrade fixes: 4c417cc

Note that those were engaged after upgrading pyupgrade from 3.3.1 to 3.15.0.

The this is the only thing we should check. Looks good otherwise

@juanitorduz
Copy link
Contributor Author

To fix pyupgrade I had to skip UP031: Use format specifiers instead of percent format because otherwise, we have Found 135 errors which I suggest not to fix on this PR and instead create an issue about it. I do not understand why the previous pre-commit did not catch this 🤔.

The precent format is used widely in the C code generation with % locals. That will take some work to refactor so definitely fine to ignore. Would be nice if we could ignore per-file if that's not too many?

There are many 😄. I would rather create an subsequent issue... What do you think ?

@maresb
Copy link
Contributor

maresb commented Jan 14, 2024

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.

@juanitorduz
Copy link
Contributor Author

juanitorduz commented Jan 14, 2024

Yeah, this PR escalated super fast 🫠🙈. If you all want we can close this one and start step by step as suggested.

@twiecki
Copy link
Member

twiecki commented Jan 15, 2024

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.

@ricardoV94
Copy link
Member

Shall we merge and open issues for the % format and the pyugrade question then?

@maresb
Copy link
Contributor

maresb commented Jan 15, 2024

Shall we merge and open issues

Ya, we could do that. The pyupgrade thing makes me a bit nervous like maybe we haven't configured it correctly. But hopefully it's just one rule they haven't implemented.

Let's merge. That'll allow me to move forward on #581 and #488.

@ricardoV94
Copy link
Member

Need to sort the conflicts with the PR we just merged!

@maresb
Copy link
Contributor

maresb commented Jan 15, 2024

Need to sort the conflicts with the PR we just merged!

Easy, it's just spacing issues. Done.

@ricardoV94 ricardoV94 merged commit ccc08ba into pymc-devs:main Jan 15, 2024
52 of 53 checks passed
@maresb maresb mentioned this pull request Jan 15, 2024
11 tasks
@juanitorduz juanitorduz deleted the ruff_linter branch January 15, 2024 13:23
@juanitorduz
Copy link
Contributor Author

🙌💪🙏

@maresb
Copy link
Contributor

maresb commented Jan 15, 2024

I opened #597 for the pyupgrade issue.

Who would like to take care of the % format issue?

@maresb maresb mentioned this pull request Jan 15, 2024
11 tasks
@juanitorduz
Copy link
Contributor Author

If there is no expected “deadline” I can take it and work on it bit by bit 🐢

@maresb
Copy link
Contributor

maresb commented Jan 15, 2024

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?

@juanitorduz
Copy link
Contributor Author

I'll do so once I'm on a proper pc (👶 at the moment 😅)

@juanitorduz
Copy link
Contributor Author

Issue created: #601

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants