Live data from Hacker News

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

astral.sh

211–220 of 247 posts

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

#211
post #41
post #18

Earlier quoted context omitted.

We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use. Another option would be to leave both topics alone and go on with our lives, improving the product, fixing bugs, implementing new features, and generally giving customers a better product and shareholders more value, while respectfully agreeing to disagree on the issues of style.

People tend to use tools set up in CICD and/or precommit. Without rules everyone uses their tool and is unwilling to compromise. Even if they are willing it is hard to setup tools to do exactly what you want. Default configuration is always the way.

So to the practical question: what we're gonna do today in CICD and/or precommit? "Default configuration is always the way" but which one: `ruff<0.16.0` or `ruff=0.16.0`?

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

#212
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, "…

Yep. So far I have found every auto-formatter tool to be hopelessly naive in its workings. No, sorry, I do not want my logger call to stretch over 5 lines of screen real estate, just because the silly tool doesn't allow to distinguish between logger calls and other stuff, and a log message can be > 80 characters. They often make code less readable than before. I am still traumatized from adding trailing comma to every multi-line call, due to black being "opinionated" and always moving things back to one line, making them less readable, if they are not longer than some limit. It's silly.

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

#213

ran 0.16 on a file with no config, it flags unsorted imports and `except Exception` by default now

You know how many bugs I've met working on large Python codebases over 20 years, caused by unsorted imports or `except Exception`? Yeah, you've guessed it: exactly 0 bugs. 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 oth…

I don't think people expect import sorting to fix bugs. It's just good (and free!) practice.

Anyway I have definitely had linters like Ruff catch bugs. Probably the most common is the mutable default argument gotcha.

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

#214
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…

There are some really bad linters out there like Rubocop so if they have had experience with those I get it.

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

#215

Earlier quoted context omitted.

Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.

Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it…

Aren't you supporting the GP's point though? If you auto-format all the things, they will likely not be right for people either, neither for the narrow terminal window, not for the widescreen full size window enjoyer. And there was energy spent on making it so, without it being a clear winner. Instead we could just be respectful and leave such things as they are, and not have to discuss this at all.

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

#216
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, "…

FWIW, ruff sees your line comment and keeps each item on its line. It only adds a trailing comma and additional space. 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 -}…

(am not the GP)

I personally like double quotes, because in so many other languages they are for strings, while single quotes are often for other things. But somehow many people have a single quotes obsession in Python. I am guessing, that it is because of ease of typing them on a US keyboard layout.

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

#217
post #125

Earlier quoted context omitted.

This seems like a strange hill to die on. Linters don’t consume energy, that’s the entire point. They get everyone on the same standard so that no energy is wasted by anyone on having to discuss, debate, and implement these standards. And yes, there are instances where someone’s non-standard coding style is not a problem. But there are instances where it absolutely can be, and these tools help there. I’m also not sur…

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

If you change the formatter for your project then yes, you have a single commit where you reformat your project and then commit this.

A single commit after a tool change. I don't see the problem.

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

#218

Earlier quoted context omitted.

Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it…

Aren't you supporting the GP's point though? If you auto-format all the things, they will likely not be right for people either, neither for the narrow terminal window, not for the widescreen full size window enjoyer. And there was energy spent on making it so, without it being a clear winner. Instead we could just be respectful and leave such things as they are, and not have to discuss this at all.

No. Auto-formatters have a way of getting people out of the mindset of arguing about it and just accepting that's the way it is. It's not that different from, say, using a compiled language instead of assembler. You and I might have differing ideas about how to write the best assembly code. If we standardize on C, it's likely neither of us will love the compiler's output, but short of outright bugs we'd move past that and go back to writing code.

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

#219
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, "…

this is why i like golang these sorts of things just don't matter, go fmt move on with life.

Same for rustfmt.

I love gofmt, rustfmt, ruff.

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

#220

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…

> with every version introducing a bunch of new default rules which you then have to deal with immediately

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

Post reply on HN