Use ruff to format and lint Python code

[alexreinking]

Ruff is a formatter and linter for Python. This PR shows what would happen to our codebase if we were to adopt it. I believe this is a useful tool, and it does not mangle our formatting too much. There are a few stylistic pain points:

1. Method chaining isn't really a "thing" in Python. We need to manually parenthesize and use breaking comments.
2. The select expression looks awkward when all its arguments get their own lines. We could adjust the API to allow taking (cond, val) tuples, which would at least pair these up.
3. Ruff (like Black and most other Python formatters these days) strongly prefers double quotes to single, unless using single would save space (e.g. because of escaping).

Using the linter produced a few classes of changes:

1. String formatting has been normalized to use f-strings.
2. Unused imports revealed places that code has been haphazardly disabled. I adjusted the build to correctly mark python_correctness_extern as skipped until we implement it.
3. Many values are evaluated for their side effects, apparently just to see if they crash. The linter insisted upon removing the unused variable names to which they were bound. We might want to do something different here.

GitHub Actions has been set to enforce these rules.

---

To run locally in a standard venv, you can install ruff via pip:

$ python -m pip install ruff
$ ruff check
$ ruff format

If you have uv installed, prefer to use uvx ruff check and uvx ruff format (no need to pip install).

[mcourteaux]

In general the changes look good, except for a couple places I spotted. I never used ruff, so not sure if they can be fixed with formatting rules. Line length limit for the C++ part is nice: no strict limit, you can author it manually: either insert the newline, and clang-format will keep it, or delete it and clang-format will not insert one. Can ruff do this too?

One other strange thing I noticed is that a few single-letter variables became two letters, like l became lv. Is that a ruff automatic change?

[mcourteaux]

This is unfortunate. # fmt: off and # fmt: on would be the equivalent for ruff.

[alexreinking]

It is... I'd rather see this, but it requires a deeper code change:

    color_image[x, y, c] = hl.select(
        (c == 0, 245),  # Red value
        (c == 1, 42),  # Green value
        132,  # Blue value
    )

[mcourteaux]

This is bad. Line too long?

[alexreinking]

Yeah, the line is too long here. I think the built-in limit is 88.

[mcourteaux]

Not nice. Line length setting might be too strict?

[alexreinking]

These I can live with, but maybe the solution is to increase the width to 120

[alexreinking]

In general the changes look good, except for a couple places I spotted. I never used ruff, so not sure if they can be fixed with formatting rules. Line length limit for the C++ part is nice: no strict limit, you can author it manually: either insert the newline, and clang-format will keep it, or delete it and clang-format will not insert one. Can ruff do this too?

Ruff doesn't support having no limit and it will try to pack things onto one line if the limit is made very large. The default is 88. We can see what happens at, say, 96 or 120.

https://docs.astral.sh/ruff/settings/#line-length

One other strange thing I noticed is that a few single-letter variables became two letters, like l became lv. Is that a ruff automatic change?

No, that's not automatic (thankfully). It doesn't like lowercase l as a variable name (and I pretty much agree with that). In some places, where L was a better name (like in the color palate code), I used that. Here, I used lv as an abbreviation for "level".

[steven-johnson]

Yeah, overall I definitely like this more than the status quo

[alexreinking]

I don't know where these C++ errors are coming from (LLVM 20 injection?) as no C++ files are modified here.

[alexreinking]

LLVM 20 failure is unrelated