Live data from Hacker News

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

astral.sh

31–40 of 247 posts

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

#31
post #6

Ruff v0.16 has a small number of breaking changes Why. Why must my poor semver be hurt so! I sorta kinda get why `ty` is pre v1.0.0 -- it's a typechecker that doesn't check a huge number of types. But what are we waiting for with `ruff`? Surely it's eaten whatever the old options were (black? maybe a few takes on py+lint?) by now many times over, and is even more dominant than `uv`. I run this program hundreds of tim…

It's conventional for semver to allow breaking changes for 0.x minor releases (but not for patch releases).

Yes but the question is why Ruff has not released v1 yet. They’re clearly used in production and the entire purpose of v0.x is to signal a project is early in development and is expected to have coarse edges.

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

#32
post #6

Ruff v0.16 has a small number of breaking changes Why. Why must my poor semver be hurt so! I sorta kinda get why `ty` is pre v1.0.0 -- it's a typechecker that doesn't check a huge number of types. But what are we waiting for with `ruff`? Surely it's eaten whatever the old options were (black? maybe a few takes on py+lint?) by now many times over, and is even more dominant than `uv`. I run this program hundreds of tim…

Why must my poor semver be hurt so!

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.)

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

#33
post #12

The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing with others on what "good" Python code should look like -- doesn't stop to amaze me. Here's "bad" code: important_numbers = { 'x': 3, 'y': 42, # Answer to the Ultimate Question! 'z': 2 } Here's what "good" code should look like: important_numbers = {"x": 3, "…

It’s because you forgot a comma after the last item. If you had kept that the items wouldn’t have been compacted (at least in black, I’ve stopped linking my code because it breaks intends of formatting more often than it helps)

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

#35
post #13

Earlier quoted context omitted.

Those tools actually save team energy. Without them any programmer has different opinion on formating, code quality, what is readable etc. You can discuss it endlesly or you can just use ruff.

Gods forbid I talk to people I work with, learn their preferences, and figure out the way we can accommodate each other. Sounds like such a waste of energy. It’s so much better if we all acquiesce to the preferences of some people neither of works with!

You can still talk to them about more important problems than placement of collons and closing bracket.

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

#36
post #10

I wish Go had something like Ruff! A lot of languages are getting amazing tool but Go has a very fragmented ecosystem with a lot of tools but none of them feel as high quality has the likes of Ruff, Oxc, Biome or even PHP's Mago

It does and it is even better. It is called the Go Analysis Framework ( https://pkg.go.dev/golang.org/x/tools/go/analysis ). 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 extremel…

That sounds amazing! I do hope golangci-lint and the likes pick it up, I'm a big fan of the strict by default approach that Ruff and other linters have taken.

Gofmt is great but it's still not very strict, the amount of times my colleagues have argued about formatting in Go is still too great, stuff like consts, types, funcs, methods order, struct initialziation newlines and other details that do matter, but they should be decided one and then applied everywhere like that.

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

#37
post #20

Earlier quoted context omitted.

The point of the "grammar nazi" bots is to focus on the actual problems: if a bot is deciding about linting, you don't have to waste brain power to discuss it in PRs. 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…

In my previous place, discussions on coding style were forbidden in PRs. It worked just fine. Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.

Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them.

That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind.

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

#40

Earlier quoted context omitted.

The point of the "grammar nazi" bots is to focus on the actual problems: if a bot is deciding about linting, you don't have to waste brain power to discuss it in PRs. 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…

I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.

Silicon Valley (the TV show) memed about it with its tabs vs spaces bit. It used to be a thing for sure. It has been a good 10 or 15 years since I had such a discussion. Automated linting and formatting tools largely killed it in my experience.
Post reply on HN