Start applying ruff rules (RUF) #9153
Conversation
RUF003 Comment contains ambiguous ` ` (NO-BREAK SPACE). Did you mean ` ` (SPACE)?
DimitriPapadopoulos
requested review from
fjetter and
jacobtomlinson
as code owners
DimitriPapadopoulos
force-pushed
the
RUF
branch
from
ad13ff7 to
86fd6d2
Compare
RUF007 Prefer `itertools.pairwise()` over `zip()` when iterating over successive pairs
RUF010 Use explicit conversion flag
RUF015 Prefer `next(...)` over single element slice
RUF017 Avoid quadratic list summation
RUF046 Value being cast to `int` is already an integer
RUF051 Use `pop` instead of `key in dict` followed by `del dict[key]`
DimitriPapadopoulos
force-pushed
the
RUF
branch
from
86fd6d2 to
9129511
Compare
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 27 files ±0 27 suites ±0 9h 53m 30s ⏱️ - 2m 58s Results for commit 9129511. ± Comparison against base commit 0771baa. |
jacobtomlinson
left a comment
jacobtomlinson
left a comment
There was a problem hiding this comment.
There are some good readability and performance improvements in here thanks! Are you not enforcing because they require manually fixing? If they need manual work then I think we should not enforce them.
Personally I would only use next(iter(...)) in cases where performance matters as it's not so novice friendly. If we really want to get away from x = list(...)[0] we can always use [x, _*] = ... which can be easier for novices to parse than x = next(iter(...)).
I also think RUF010 reduces readability by using advanced f-string expressions. The original code was already very readable.
2 participants
I am not enforcing these rules yet.