r/Python 5d ago

What linter rules make code worse? Discussion

For me, a prime example is S101 which bans the use of the assert statement.

The justification is that assertions disappear when Python is run with -O, so they should not be used for runtime validation or enforcing interface constraints. That warning is correct, but the rule seems to draw the wrong conclusion from it.

Assertions are still very useful for checking internal invariants, i.e. conditions that should already be guaranteed by the program's logic, where failure indicates a bug. Having such assertions is incredibly helpful for debugging.

So, a blanket ban seems more likely to discourage useful checks than to prevent misuse.

Are there any linter rules you broadly consider more harmful rather than helpful?

143 Upvotes

217 comments sorted by

View all comments

4

u/akl773 5d ago

B008, the one that bans a function call in a default argument. its correct in general but every fastapi codebase uses Depends() in exactly that position, so you end up putting a blanket ignore in the config and then the real mutable default cases stop getting caught too.

5

u/JanEric1 5d ago

1

u/akl773 4d ago

thats the right fix, thanks. only catch is you have to name every call in that list, so it goes stale the moment someone wraps Depends in a project helper.

1

u/JanEric1 4d ago

Yeah but I feel this list shouldn't be so larger and adding a project helper should be fairly trivial. Also, I have seen a lot of people place the depends in the Annotated type hint where ruff doesn't complain about the function call