[ ] Static analysis is a good way to gate-keep software quality. From .pre-commit-config.yaml, I can see pytest enabled flake8 for pep8, pep257 checker. Is there any reason to skip pylint?
[ ] pytest and operating system versions: pytest-5.4.1.dev127+gf479cbce1
Is there any reason to skip pylint
Adding a second linter adds some maintenance overhead - in setup (CI, tox and by each developer) and in development (add ignores and such) and overhead (time it takes to run).
It might be worth it if there is sufficient added value. Would you be able to demonstrate the warnings it triggers? Regarding the two you pasted:
I think the best way to move forward with this is to open a PR with lint fixes suggested by pylint, to demonstrate its value.
Can certainly have a look, I think there is a fine line where having too many starts to become somewhat painful as a maintenance overhead, e.g something that is considered 'OK' on linter A, fails on B and vice versa, so we have to be careful not to be too over zealous (imo)
a key reason why pylint was never added is that in the past it was insanely chatty with insane amounts of false positives/nitpicks - given that in general black is used these days + tools to do such cleanups its hard or me to see value in adding pylint
@anonyknight does @RonnyPfannschmidt's answer above answer your question?
just to revisit; -1 from me on this one. I think what we have is sufficient for the project
Most helpful comment
Adding a second linter adds some maintenance overhead - in setup (CI, tox and by each developer) and in development (add ignores and such) and overhead (time it takes to run).
It might be worth it if there is sufficient added value. Would you be able to demonstrate the warnings it triggers? Regarding the two you pasted:
I think the best way to move forward with this is to open a PR with lint fixes suggested by pylint, to demonstrate its value.