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.
Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
211–220 of 247 posts
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#212The 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, "…
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#213ran 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…
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
#214The 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…
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#215Earlier 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…
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#216The 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 -}…
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
#217Earlier 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.
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
#218Earlier 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.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#219The 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.
I love gofmt, rustfmt, ruff.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#220I 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…
According to the original post
> Ruff's default rule set was last modified in v0.1.0
Which was over 2 years ago.