Closed jherland closed 6 months ago
I really like how you logically structured the problem making ruff strict - each commit tackling a different type of error.
Thanks! 🙏🏻
I think we should avoid
# noqa
comment as much as possible, or explain why we use it, but this can be a subject of another PR.
Agreed. My philosophy here is roughly this:
pyproject.toml
with a comment explaining why.pyproject.toml
for now, and explain that we will get around to it later.# noqa
comment for the issues that we will either get around to later, or that we find "acceptable" to live with indefinitely.With these pytlint -> ruff PRs, we've gone from ~30 # noqa
and # pylint
comments before to ~60 # noqa
comments after these PRs. Most of this is because ruff simply has more checks to push our code into a better shape, overall.
An important goal is of course to minimize the number of # noqa
comments, and to that end, I look very critically at # noqa
comments that I encounter while refactoring code. But trying to fix them all in this PR is not feasible. As long as there is a general trend towards decreasing these, I'm happy.
Re-configure
ruff
to enable as many checks as feasible, and fix various issues throughout our codebase. The second PR in a series of 3.Commits:
ruff
to be much stricterset(<generator>)
->{<set comprehension>}
assert False
->pytest.fail(...)
@pytest.mark.parametrize
.keys()
str()
set([...])
->{...}
.get()
if-else
block@pytest.fixture()
over@pytest.fixture
_
in parametrized argsPath.*
methods where availableyield from
instead offor
-loop withyield
insideif
-conditions[foo, *bars]
instead of[foo] + bars
elif
instead ofelse
+if
where possiblebool
flag arguments to functions are always namedUnparseablePathException
->UnparseablePathError
Path()