Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

It is what it is, everyone gets the same, shut up and work on what matters.

I'm surprised you consider it a lot of energy spent, I tend not to spend any on this, it just runs automatically on my code and I drop out of pretty much every discussions about linting as it's good enough with automated tools.

I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.

In short, you seem to have a grievance against linters that goes way past reasonable. You assert this example you give is "perfect" below. You also complain linters waste time and commits despite able evidence in the field they do the opposite.

You seem willing to add drama, grievance, and personal bias to what could have been a rather straightforward technical discussion. The sum of which is: linters sometimes make changes to code that I don't like.

I'd encourage you to reconsider what's really important when it comes to team development and try listening more to those around you. You seem overly focused on asserting your opinion instead of having a discussion.

These types of exchanges are usually very unproductive and stressful in a team environment. They are evidence, IMO, of a dev having the wrong priorities. I'd encourage you to step back and really consider how you view craftsmanship in a team dynamic and whether or not you are fighting the right battles.

It also does not collapse lines when there’s a trailing comma.

Your output seems to be from black. IMO it’s insane to collapse lines when there are line comments.

  $ uvx ruff format --diff formatting.py
  --- formatting.py
  +++ formatting.py
  @@ -1,8 +1,4 @@
  -no_comma  = {
  -    "x": 3,
  -    "y": 42,
  -    "z": 2
  -}
  +no_comma = {"x": 3, "y": 42, "z": 2}
  
  with_comma = {
       "x": 3,
  @@ -12,6 +8,6 @@
  
  comment = {
       "x": 3,
  -    "y": 42, # Answer to the Ultimate Question!
  -    "z": 2
  +    "y": 42,  # Answer to the Ultimate Question!
  +    "z": 2,
   }
  
  1 file would be reformatted

I’m also not sure I understand the “ My place used pylint, flake8, black, ruff -- with hundreds of commits on every change”. These tools don’t add extra commits. You run them prior to your PR, get them aligned with the linting, and then commit the change you were already going to make. Thats 0 extra commits.

For someone ultimately arguing that there is too much effort spent on people’s coding styles, you are spending a lot of effort arguing about people’s coding styles. These tools are some of the most set it and forget it things around.

I find that people who argue against automatic linting and formatting tend to be the same that would argue incessantly about style. So much wasted energy, I want none of that.

Also, in your example above, if you put the comment on the line _above_ instead of inline the formatter will most likely do the right thing.

100%. Almost all of my time burned navigating code is not hung up on stylistic conventions but on nasty services with inconsistent abstractions and patterns.

BUT, conventions and consistency make code easier to read and write, period. If you’re debating over single or double quotes that’s almost a fireable offense IMO.

Additionally, when you have a culture that delegates to tools as much as possible, the focus sharpens in a healthy way.

But one thing I bring to every team is this: “I don’t want to look at a file and say that is Tom’s code or that is your code. What I want to see is [project name] code.”

With regards to your example, adding a comma to the final element should preserve multi-line. You just don’t know the formatting rules yet apparently

I also need something to save me from my regexps, the verbose flag helps a lot. but what would be really nice is some sort of python subset that could compile to the state machine. I would also like composable expressions, that is, composable at the graph level not the string composition we are forced to use. And a pony, I would also like a pony.

As you can tell I am not a fan of APL, not because of what it can do but because of the super compressed syntax it adopts. see also: perl

If you add an extra dangling comma at the end of the last item, ruff/black will auto-format to the line-by-line style you like.

This seems like a case where the tooling is compensating for unclear conventions. Collaboration tools are useful, but it may be more effective to strengthen the code specifications and documentation practices first, so intent lives in a predictable place instead of being scattered through implementation details.

It is fairly new so not well known but it is what powers go fix and go vet under the hood. And I believe the Go team is currently working on making it possible for module authors to easily describe their own custom analysis passes that would run automatically when running go fix.

It is extremely easy to define your own analysis.Analyzer struct that describes your own static analysis pass. You get access to all sorts of useful information such as the AST, types, even SSA info and you can even compose the information between analyzers. Then you can easily compile it into a binary and run it by passing that binary to go fix with a command line flag. The go toolchain itself handles all the complex caching logic so that your analyzers run fast.

Since it is made by the go team itself and part of the toolchain it should slowly become the unified standard you are looking for. So hopefully golangci-lint and others should eventually all unify under this framework.

You can easily give it a go by telling some AI agent to write some Go Analysis analyzers and telling them to drive them with go fix. My Go projects tend to accumulate a bunch of these to enforce all sorts of rules deterministically and automatically instead of some imprecise markdown file.

Granted, this is a linter, not a formatter, but my larger point is I am glad that Python ecosystem evolved like it did recently.

Compare that to Python or TypeScript which are Wild West languages without opinionated first-party tooling, and it’s clear why Ruff/Biome feel great.

You just wouldn’t get that same high with Go.

Not sure what you're talking about.

(Honestly go's distributing itself has covered a lot of it)

Don't get me wrong, the new level of details coming from Ruff is much appreciated and a good thing :)

Two approaches:

You can pin the version of `ruff` in `pyproject.toml`.

You, to let ruff command version advance but pin the settings to a prior version:

    uvx ruff@0.15.22 check --isolated --show-settings | flat2toml > pinned.toml
    

    extend = "pinned.toml"

According to the original post

> Ruff's default rule set was last modified in v0.1.0

Which was over 2 years ago.

https://github.com/astral-sh/ruff/releases/tag/v0.1.0

Not unlike that experience, I also saw coding agents spend lots of tokens trying to fix a benign issue, as well as doing the opposite - like disabling the tests !!! when they don't pass. :facepalm:

I grew to trust AI results in terms of overall correctness, but I still have hard time trusting their *judgement* on the *code quality*.

It's really annoying how many people think that if you enforce stupidly strict rules about formatting, more strict that those of Fortran in 70s, you'll automatically get good code.

I've seen companies that enable 100% of ruff rules, use several other linters, and enforce other rules (like every variable name should be at least 20 characters long to fully describe its purpose). And they have awful buggy unmaintainable code. But it is nicely formatted (although reading code where half of the screen estate is consumed by the variable name is a bit difficult) and has no "dreadful" `except Exception`. Or every mutable class attribute variable is annotated with `typing.ClassVar` (RUF012 - the most idiotic rule I've ever seen). Nevermind that it doesn't really stop anyone from changing value of that attribute. You must annotate it with `ClassVar`!

It's an idiotic cargo-cult.

It is fully according to their versioning policy:

https://docs.astral.sh/ruff/versioning/

But also compliant with semver:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/

(Maybe I misinterpreted your remark, but semver does not get hurt.)

What's really tiring is reading such facile "critiques", especially when they are not even applicable.