gh-132390: Apply Ruff linting to Tools/build

[picnixz]

• Issue: Lint Tools/build using existing ruff configuration #132390

[picnixz]

@AA-Turner @hugovk Does it look acceptable or would you prefer to just exclude the files instead of ruffing them?

[picnixz]

I'll actually hold the merge a bit more so that code owners can also give their opinion.

[AlexWaygood]

Looks like a nice cleanup to me, but I'm not the person maintaining most of these scripts :-)

make sure to get signoff from the relevant maintainers before landing this. Not everybody on the team is necessarily on board with stricter linting in CI!

[AlexWaygood]

why remove these from the select list? I like them (but I'm biased -- I wrote a lot of the lints originally as part of the flake8-pyi plugin 😆)

[picnixz]

This one recommends Set -> AbstractSet and namedtuple -> NamedTuple. Are there other interesting rules there that would be better enabled? (I don't think those two rules should be enforced so I ignored them but I think Adam just removed the PYI* rules altogether)

[AlexWaygood]

The first of those is only a stylistic lint. But it's a stylistic lint that I agree with -- it is confusing that collections.abc.Set has that name, since it means something very different to builtins.set or typing.Set.

The second of those is arguably a correctness rule if you're running a type checker in CI: it encourages you to use a version of namedtuple that gives type checkers much more information to work with.

You can see in flake8-pyi's original documentation that there are many lints in this category that are related to the correctness of annotations, not merely questions of style: https://github.com/PyCQA/flake8-pyi/blob/main/ERRORCODES.md. (I'm linking to the original flake8-pyi docs as we don't have a summary in Ruff's docs that's quite as convenient, but the implementation isn't very different at all in Ruff's version, so the information still applies.)

Since we run mypy on at least one of these scripts in CI (and we may start doing so with more of them in the future), I think lints that enforce correctness of type annotations are pretty useful:

cpython/.github/workflows/mypy.yml

Line 13 in 1d97488

- "Tools/build/generate_sbom.py"

[AlexWaygood]

(I don't think those two rules should be enforced so I ignored them but I think Adam just removed the PYI* rules altogether)

Ah yes, I see this is one of the changes @AA-Turner made in his commits to this PR branch

[picnixz]

make sure to get signoff from the relevant maintainers before landing this. Not everybody on the team is necessarily on board with stricter linting in CI!

Yes, that's why I eventually decided to hold off the merge!

[picnixz]

Ok so here is how I decided to make the change:

• use f-strings instead of .format(); both have the same readability IMO.
• do not use f-strings for %s when it's less readable. And if there are enough occurrences of %-usage, just ignore it for the file (namely generate_token.py)
• if %-style and f-strings are roughly the same readability and the file already uses f-strings elsewhere, make everything f-strings (smelly.py)

[sethmlarson]

LGTM for generate_sbom.py.