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

linter: ruff coverage #834

Closed
jku opened this issue Jun 27, 2024 · 3 comments · Fixed by #836
Closed

linter: ruff coverage #834

jku opened this issue Jun 27, 2024 · 3 comments · Fixed by #836

Comments

@jku
Copy link
Collaborator

jku commented Jun 27, 2024

The various linters have been replaced by ruff (thanks to @L77H).

  • We should have a look at the ruff rulesets and decide which are most interesting (and best value for effort): https://docs.astral.sh/ruff/rules/
  • Also should look at current ignores (both noqa comments and the ignore list in pyproject) and see if we can improve code

As a initial list, these contain useful rules

  • RUF
  • UP: this contains "use f-string instead of format" error which we're going to see a lot of. flynt tool may allow automated conversion to f-strings but we need to be very careful with that
  • pylint extended rulesets PLR, PLE, PLC, PLW
  • various flake rulesets: ANN at least

I have not tested how much work enabling them would be -- starting with the easiest may be a good idea

@L77H
Copy link
Contributor

L77H commented Jun 27, 2024

I tested the initial list you proposed:

  • Using PL as a rule includes the following: PLR, PLE, PLC, PLW so those are already covered
  • UP finds a total of 44 errors, of which most are f-string related as you already assumed
  • ANN finds a total of 532 errors

I believe this is a good starting point to be added, I will create a separate PR for both UP and ANN if you agree.

@jku
Copy link
Collaborator Author

jku commented Jun 27, 2024

Using PL as a rule includes the following: PLR, PLE, PLC, PLW so those are already covered

oh that makes sense -- I got tricked since pycodestyle is documented the same way but that one doesn't seem to have a "top-level" ruleset

Which reminds me: pycodestyle warnings (W) might be useful to enable as well

@L77H
Copy link
Contributor

L77H commented Jun 27, 2024

Yes the markup is a bit confusing.
Good, I will add W to the TODO list.

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

Successfully merging a pull request may close this issue.

2 participants