astral-sh
Disable D203, D212, D213 and S101 by default
(see our discussion in #2289 as well as the commit messages for the reasoning)
Does specifying tool.ruff.pydocstyle.convention still activates the rules D203, D212, and D213?
Good question. Previously pydocstyle.convention only disabled rules, it never enabled them, so if you didn't also select them via D it wouldn't turn them on. I do not want the new explicitly_enabled logic to somehow take the presence of a D selector into account since I think that would overcomplicate the rule selection behavior ... so I'll change pydocstyle.convention to enable these rules even if D isn't selected ... even if that is a bit of a breaking change I think it much better aligns with the probable user intention.
(Marking this as a draft till I implement that ... probably only have time for that in a couple of hours.)
D203 and D213 aren't part of any of the valid conventions. (D212 is, and shouldn't be part of any sort of automatic disable list IMO.)
Just an update:
- I'd firstly like to fix the config resolution situation #2312.
- Then I'd like to convert the
pydocstyle.conventionsetting into a rule selector ... so you could e.g.--select pydocstyle:googleand then ignore a specific rule from that rule set with--ignore - And then finally disable these problematic pydocstyle rules by default by implementing the changes in this PR.
Regarding the assert one, clippy deals with this by having a clippy::restriction group that is off by default, and is not meant to be enabled wholesale, but contains lints which can be enabled for specific code bases which want to enforce that some feature is not used (see lint list here). I can imagine this being useful for some Python projects, e.g. enforce no assert, no async/await, no :=, no breakpoint(), or even no exceptions.
@not-my-profile - This came up again recently (#2368). What can we do to prioritize turning those D rules off by default?
I'd like to start by just disabling the D rules, and we can revisit the other cases later.
Closing this for now since ba26a60e2a49716da4bd0a01b7faad17b9094216 has addressed the issue that prompted this PR.
The tracking issue for the more flexible rule categorization is #1774.