Replies: 4 comments 18 replies
-
|
Upvote this comment if you often use Ruff’s current default rules instead of overriding them entirely with |
Beta Was this translation helpful? Give feedback.
-
|
Respond to this comment if there are any rules included in this list that you would disable for your projects if this became the default rule set |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for acting like I have a strong stance on this, thanks for the civility and explanations. |
Beta Was this translation helpful? Give feedback.
-
|
hmm, yeah, I agree that Logging the error and carrying on is definitely the right thing to do in some situations, but I'm still not convinced that it's normally what you should do. Personally, I'd be okay saying that you should have to manually disable the rule if you're working on a codebase where you run into these situations frequently -- and that if it's not a codebase where this often comes up, you'll just have to But maybe the fact that we might want to split the rule up suggests that we should hold off adding it to the default ruleset for now. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at my own globally shared configs: https://github.com/BesLogic/Beslogic-Ruff-Config/blob/main/ruff.toml
# contextlib.suppress is roughly 3x slower than try/except
"SIM105", # flake8-simplify: use-contextlib-suppressI have # False-positives
"TC004", # https://github.com/astral-sh/ruff/issues/3821PEP 695 is annoyingly still not supported by Pylance... But please let's push them to update, maybe a default # Not colored correctly in Pylance https://github.com/microsoft/pylance-release/issues/6942
"UP047", # non-pep695-generic-function
# Typeshed doesn't want complex or non-literal defaults for maintenance and testing reasons.
# This doesn't affect us, let's have more complete stubs.
"PYI011", # typed-argument-default-in-stub
"PYI014", # argument-default-in-stub
But it's often out of stubs author control (and as I just mentioned, not sure if all those cases are currently addressed) [lint.per-file-ignores]
"**/typings/**/*.pyi" = [
# The following can't be controlled for external libraries:
"N8", # Naming conventions
"PLE0302", # The special method expects a given signature
]Setuptools also has "PT012", # pytest-raises-with-multiple-statements, avoid extra dummy methods for a few lines, sometimes we explicitly assert in case of no error
"TRY301", # raise-within-try, it's handy
"UP015", # redundant-open-modes, explicit is preferredThat open mode preference is also a current feature request: #18435 (comment) pywin32 also disables |
Beta Was this translation helpful? Give feedback.
-
|
Thanks all for the feedback! I'm incorporating it into the first draft of the new rule set in #23385. @Avasam I think the issue with I think I agree with the rest of your suggestions. I've been on the fence about including any of the The one rule I might push back on slightly is
|
Beta Was this translation helpful? Give feedback.
-
|
Pretty much agreed with your entire answer. Setuptools just removed a ton of code (and tests) with the removal of I just ran ruff with |
Beta Was this translation helpful? Give feedback.
-
|
Respond to this comment with any rules excluded from this list that you think should be enabled by default |
Beta Was this translation helpful? Give feedback.
-
|
Based of the projects I publicly actively maintain:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for these suggestions too!
It looks like I categorized the other rules here as being on the pedantic/restrictive side of stylistic lints. I don't feel too strongly about that, although given the size of current set I might go ahead and leave them out for now. I'll keep them in mind, though! |
Beta Was this translation helpful? Give feedback.
-
|
Edit: I got confused and read The only other one in here I'd like to make an argument for, is These are just suggestions and I personally start from |
Beta Was this translation helpful? Give feedback.
-
|
Bit of a lazy post, but this is approximately the config we use at work: Config: DetailsI see a few ones you're suggesting that we explicitly disable, and vice versa |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We’ve been working on a new default rule set for Ruff with the goal of reducing the amount of configuration required to start using Ruff, while also capturing the benefits of rules that are currently disabled by default.
The proposed rule set is significantly larger than our current defaults, containing 436 rules, up from the 59 rules in the stable default set. It also expands beyond the primary focus on “correctness” rules in the current default set to include rules that are consistent with widely-accepted Python idioms or styles.
We’re hoping to release the new rules in preview this month, but even before that, we wanted to get some feedback on the rule set. You can find a simple
ruff.tomlfile containing the new rule set attached to this post and in the collapsed section below. We’d love any feedback you have, but I’m also including some more specific prompts in the discussion thread.Config file
ruff.txt (TOML file with the extension changed for GitHub's upload requirements)
You should be able to try this out in your own project with something like:
ruff check --isolated --no-cache --config "$(curl -L https://github.com/user-attachments/files/25394860/annotated.txt)"Beta Was this translation helpful? Give feedback.
All reactions