Live data from Hacker News

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

astral.sh

191–200 of 247 posts

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

#191
post #181
post #125

Earlier quoted context omitted.

> These tools don’t add extra commits. When you replace tool x with tool y, you need to fix your code, because these tools do not agree on what your code should look like, and what was acceptable for tool x simply isn't for tool y. One of these changes I mentioned brought a massive reformatting of all code base, as the new tool failed 'import' statements unless they were in alphabetical order.

Sounds like the issue is not the tools themselves, but that the project management / stewardship allows someone to replace tools willy-nilly leaving others to pay the cost of migration? At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task th…

The linked article says that ruff now has 413 default rules -- instead of 59 previously. Do I understand it right that all the projects that were using ruff were 100% conformant to 59 rules yesterday but likely not conformant to 413 rules today, which will cause breakage all across the board? Likely immediately followed by a swarm of pull requests all formatting their code in conformance to whatever these new (413-59) rules are?

There's no "tool replacement" going on here.

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

#192
post #44

I updated a ~3k line Python project with this the other day. I was using v0.15.x beforehand. It didn't take too long and the new rules do improve code quality. It caught quite a few things previous versions didn't. Here's a few commits of changes: (A whole bunch of manual changes based on its suggestions) https://github.com/nickjj/plutus/commit/9af66d31f98bef841588... (Re-enable line length) https://github.com/nickjj…

[flagged]

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

#194

Great to see ruff, ty and uv being actively developed, even after Astral was acquired by OpenAI.

Tbh I was super enthusiastic about Ty but it’s just so far behind basedpyright I had to switch off it. The lack of checks wasn’t the issue, it was the false positives which were the real dealbreaker. That and it doesn’t have support for baselining, which is such an insanely awesome feature for larger codebases. uv and ruff are incredible though. Maybe someday on Ty.

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

#195
post #112

Earlier quoted context omitted.

And here's where this abstraction breaks: when a programmer leaves, their code is not going anywhere. The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

> The bigger problem is this: you want me to be a cog wheel, but I want to be an artist. Well, that's the ball game then. This isn't the industry to be an artist in, especially post-AI.

I think the artisanal code industry will exist. It will not be large and it will not pay well.

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

#196
post #143

Earlier quoted context omitted.

I've read through all the sub-comments you've left here. 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…

My issue with your comment is not that it seems to offer unsolicited psychological advice completely out of the blue; it's that it leaves me with an uncanny feeling that it was written by an LLM. In a thread where I complain about the de-humanisation of my profession by the bots , the irony of having a bot's psychological advice (and so, de-humanising the discussion too) is not lost on me.

If you are really concerned about my being a bot, a quick look at my comment history, going back over a decade, should dispel that concern.

Edit: I once had someone apply for a job and their written communication was pretty caustic. After rejecting their application, I wrote and explained how unprofessional I found their interactions, encouraging them to step back and reconsider how their communication appears from the other side.

To my great surprise, they wrote back and said they had never had anyone give them such feedback and they agreed with my assessment of their interactions. They just had never seen it before. They thanked me for the feedback.

Such interactions are exceedingly rare. But I sometimes offer unsolicited advice on the off chance that said advice can make a difference.

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

#197
post #112

Earlier quoted context omitted.

The one day, your chef leaves, the food goes to shit and productivity/output/morale drops. When the new chef arrives, then everyone has to relearn everything. Software shouldn't be bespoke and "artisan".

And here's where this abstraction breaks: when a programmer leaves, their code is not going anywhere. The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

Take it to your employer then, not to us.

We want maintainable code we can quickly onboard in, and be able to modify and extend. Your artistry is getting in the way of other people getting stuff done.

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

#198
post #113
post #70

Earlier quoted context omitted.

You may do as you like in your projects. You might even find you can make a formatter enforce that rule which is apparently important to you. 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.”

You want to be a cog wheel, in a company of cog wheels. There's nothing wrong with that. But I want to be an artist, and preferably in a company of artists, having been in a company of cog wheels too many times. Not only it's more fun that way, but also tends to lead to better outcomes.

Wowsers. As what I think is a fellow traveler, I would encourage you to look back at all the places you created art and ask how many friends you made at each stop.

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

#199
post #64

Earlier quoted context omitted.

Sorry, but I did not "forg[e]t a comma after the last item". I intentionally did not put a comma there. The list of the "important numbers" in my example is already complete and perfect, and is not supposed to ever change. I wanted to emphasise this fact by specifically omitting the comma there, in the hope that intelligent people in the future would get this message exactly as I intended for it to be.

[flagged]

Yeah, but artfully dropped.

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

#200
post #191
post #181

Earlier quoted context omitted.

Sounds like the issue is not the tools themselves, but that the project management / stewardship allows someone to replace tools willy-nilly leaving others to pay the cost of migration? At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task th…

The linked article says that ruff now has 413 default rules -- instead of 59 previously. Do I understand it right that all the projects that were using ruff were 100% conformant to 59 rules yesterday but likely not conformant to 413 rules today , which will cause breakage all across the board? Likely immediately followed by a swarm of pull requests all formatting their code in conformance to whatever these new (413-5…

Well, that's the danger of using software without version pinning.

Also, usually tools like Ruff can be configured to enable/disable project-specific formatting rules (via a config file), allowing you to suppress the defaults you disagree with, or whose consequence you don't want to deal with _right now_. Some tools might even support suppressing specific rules per-file, so you can migrate codebase over time instead of in one go.

Having a config that explicitly defines the rules enforced in the project is really useful, and perhaps even crucial the bigger the project grows.

Post reply on HN