Switch to ruff and black code style

[jnikula]

This is a sort of alternative to #296 from @LecrisUT. I've had most of this laying around in a local branch for months, but it got stalled because of the black code style. There are a lot of elements in it that I simply loathe (e.g. the double blank lines, often having \n after the opening brace of a function call, etc.) but I do see value in never having arguments about style. I guess it's also common among Python projects.

The alternative would be to only use ruff check and not ruff format, because the latter is strongly opinionated with very little configuration.

I'd appreciate @BrunoMSantos's views on this as well.

[jnikula]

As opposed to #296, this is a gradual migration with every commit passing make check. More categories can be gradually selected in the future.

[LecrisUT]

but I do see value in never having arguments about style. I guess it's also common among Python projects.

Yeah, we've mostly lost that battle. It's even more tricky because some checks reuse the code of the format, so even if it allowed to configure the format, it would eventually fail block a ruff check.

As opposed to #296, this is a gradual migration with every commit passing make check. More categories can be gradually selected in the future.

Yep, perfectly cool. Went with ALL in that PR to have a list of checks to verify and tackle gradually, and to allow new rules to trickle in which are easier to investigate when the ruff version is bumped.

[BrunoMSantos]

Hey, sorry, for the delay. Personally I haven't felt any attrition due to our style rules, but I haven't kept up with recent submissions, so you're in a better position to judge.

I think we debated something like this a while back on account of black styling itself as a tool to be endured more than it is wielded. Besides, I'm a strong proponent of PEP8's own introduction.

That said, I have no direct experience with black specifically and having had a quick look at the changes, it didn't yield anything totally off putting. Not how I'd tune the code to my liking everywhere, but I probably wouldn't raise any objections either if not for consistency maybe, but that wouldn't be an issue if we went with it of course.

Finally, ruff, I'm keeping an eye on it myself to replace flake8 in my LSP chain for the greater speed, if not for black style formatting. I have no objections there.

[LecrisUT]

Should probably clarify the title because ruff is used for code style in this change not black. But I guess otherwise the same comments apply there.

[BrunoMSantos]

Yup, I should have said 'black's style', be it ruff or black the tool behind it.

Anyway, I can do a more careful review later if you want to go ahead with it, though I don't expect to find much to add.

[BrunoMSantos]

So, having gone through it, I'd say:

• The 1st two commits could go in anyway unless it's one of the changes you disapprove of. It's a couple less exceptions.

• Black's code style yielded some minor improvements (mostly with regards to consistency) and some minor downgrades to my eyes (mostly the line breaks on functions arguments). I'm net neutral on it really. If no truly bad case came up so far, I'm willing to bet on it behaving sensibly enough.

• Regardless of the style itself, changing to ruff sounds good and it seems painless enough.

This one's up to you 👍

[jnikula]

I realize this PR conflates two things together, switching to ruff the tool, and switching to black the style. I'm not going start untangling them though, let's just go for both at once.