Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

astral.sh

Post reply on HN
Print view View original

141–150 of 247 posts

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

#141

Post by coldtea »

Majestic121 wrote: post #14
maratc wrote: 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, "…

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…

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

And yet, as per the example, the bot force worse linting decisions, and even pushes towards more bugs (e.g. future readers missing the comment intention since it now applies to all 3).

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

#142

Post by coldtea »

dewey wrote: post #37
maratc wrote: post #20

Earlier quoted context omitted.

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) d…

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

Which might be more overrated OCD than anything worth it. If you like that, you can add a formatter at the end of the chain or even just when reviewing.

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

#143

Post by maratc »

rsyring wrote: post #119
maratc wrote: 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, "…

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.

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

#144

Post by maratc »

colechristensen wrote: post #138
rsyring wrote: post #119

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…

A person just as opinionated as the tool. People who have very strong opinions about formatting in any direction are suspect.

I do not have any opinion on formatting. My argument is that nobody should.

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

#145

Post by mirashii »

jon-wood wrote: post #136

I really wish Ruff would introduce something similar to Nix’s stateVersion, which is used to determine the set of defaults that will be applied. Updating Ruff at a scale beyond a single repo is a bit of a crapshoot currently, with every version introducing a bunch of new default rules which you then have to deal with immediately (either by turning them off or fixing them). I’m aware we could have an allowlist in plac…

I think the consensus is that this would be the wrong end to tackle the problem from. Your project should include ruff at the version it wants to use in its pyproject.toml. Bump the version when you're ready to spend the time on one project, but no need to coordinate across multiple projects. If you really want to do it, you can, but if there's one hold-out, you're not stuck behind forever because one project can't move yet.

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

#146

Post by toxik »

jbvlkt wrote: post #13
maratc wrote: 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, "…

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.

I have never discussed code formatting and drive-by changes more than in projects with auto formatters.

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

#147

Post by maratc »

mpyne wrote: post #137
maratc wrote: post #104

Earlier quoted context omitted.

I think you miss the point, but using your foodie reference: would you rather go to a couple of Michelin restaurants -- where each piece brings a reflection of the chef, the geographic area, and what quality ingredients were available on that day -- or would you rather only eat at McDonald's for an experience that is extremely consistent across days, seasons, and continents? Now imagine a chef who has a nice little r…

The hidden implication in your extension of the foodie analogy is that consistent food must have worse quality. That's not true, and if anything in software having consistent software delivery makes it more likely to achieve Michelin-graded level of quality, not less.

But the formatting is not all that "delivery" stands for.

I've worked on great codebases that would produce thousands of linter errors (lowball estimation), and on shitty codebases that were 100% compliant.

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

#148

Post by kstrauser »

maratc wrote: post #113
tclancy wrote: 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.

That's an uncharitable take and I urge you to reconsider. I also take great joy and pride in the art of writing beautiful code. I have no desire to be a cog in a machine. However, my ADHD brain is delighted to not have to make a million little distracting decisions in place of the code planning I should be doing. Formatters let me concentrate on writing the best data structures and APIs and algorithms instead of how many spaces to put before comment markers or while kind of quote mark is more aesthetically pleasing in this particular file.

I, too, want to be an artist. For me, the flow of data through my work is the artistry, not the typography of the code.

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

#149

Post by slowking2 »

driverdan wrote: post #114
maratc wrote: 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, "…

The other commenters seem to be commenting on style consistency but ignoring your example. Your original format is far easier to read and understand plus the meaning of the comment is lost. IMO you're completely right about this example. Single line dict definitions shouldn't exist. Dicts are far easier to understand and manage when each key/value pair is on its own line, regardless of length.

IIRC, if you put a trailing comma on the last entry, the formatter will keep multiline dicts multiline.

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

#150

Post by OoooooooO »

maratc wrote: post #135
elteto wrote: post #128

Earlier quoted context omitted.

Well, it’s nice you bring up strawmen after you called me a hobgoblin (a delicious word btw). I hope this _divine_ irony is not lost on someone like yourself. > I learned that my style is somehow "bad." That’s what you are missing: your style is not bad at all. It’s just your style. Use it for yourself! Teams work on shared ground. Automatic formatting is just part of that shared ground.

I’ve written it up-thread: you want me (and possibly, everybody) to be a cog wheel. But I want to be an artist.

That does work in private projects but not in team projects.
Post reply on HN