Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

      9 files  ±0        9 suites  ±0   3h 6m 20s ⏱️ - 10m 13s
 18 154 tests ±0   16 937 ✅  - 2   1 215 💤 ±0  2 ❌ +2 
162 614 runs  ±0  150 517 ✅  - 5  12 095 💤 +3  2 ❌ +2 

For more details on these failures, see this check.

Results for commit 7dc6abd. ± Comparison against base commit cd5e429.

♻️ This comment has been updated with latest results.

Agreed, now ignoring rule verbose-decimal-constructor (FURB157).

Sorry I mean this whole ruleset. I find many of the changes in this PR subjectively worse. We like simple code here and I don't think having extra linter rules that push us towards these patterns aligns with that.

While I agree SIM and FURB rules are the most debatable, I find the rules applied here result in much simpler code, in the spirit of https://matthewrocklin.com/write-dumb-code.html:

• f-string-number-format (FURB116) (the new code is factually simpler, I do find the new code easier to understand as it makes the intent much clearer: simple string formatting)
• if-expr-min-max (FURB136) (uses plain English min/max instead of if branches).
• redundant-log-base (FURB163) (uses log2 which is what we do when writing math formulas)
• list-reverse-copy (FURB187) (plain English word reverse instead of cryptic slices)

Not 100% certain about this one:

• for-loop-writes (FURB122) (I do find the new code simple to understand, but agree that novice programmers might not be aware of writelines).

I think FURB116 and FURB122 were the ones that I felt made things less readable for novice developers.

• As I see it, FURB116 is about using standard Python string formatting instead of reinventing the wheel. I'm not saying Python string formatting is easy to grasp for novice Python programmers, but it is standard Python and learning string formatting seems a necessity any way. Besides, the resulting code is much simpler. Finally, string formatting is used elsewhere in dask, for example:
  

  dask/dask/dataframe/tests/test_dataframe.py

  Line 565 in 1ab0d43

  index = [f"row{i:03d}" for i in range(100)]

• I wasn't certain about FURB122. On second thoughts, it's simply a suggestion to use a standard Python function, in the exact context this function has been designed to be used in. The purpose of the function is easy to understand because its name is simple English. Here the rule is applied to a test, but it could make a difference in I/O bound code (otherwise the function would probably not have been added to Python).

@jacobtomlinson I have further simplified the FURB116 fix, I think it's much cleaner now. I can ignore FURB122 if you really don't like this rule.

My understanding is that writelines is about perf gain, as it involves less system calls. Otherwise, why would the function have been added to Python? See for example Writing to a File from the Python Cookbook:

Calling writelines is much faster than either joining the strings into one big string (e.g., with ''.join) and then calling write, or calling write repeatedly in a loop.

I must admit the documentation of FURB122 is not clear about the perf gain, but that's probably a documentation bug:

When writing a batch of elements, it's more idiomatic to use a single method call to IOBase.writelines, rather than write elements one by one.