[flagged]
Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
121–130 of 247 posts
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#122The 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 agree with you, but that is literally what ruff is meant to do, and what this person is arguing against.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#123ran 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 other linters, and enforce other rules (like every variable name should be at least 20 characters long to fully describe its purpose). And they have awful buggy unmaintainable code. But it is nicely formatted (although reading code where half of the screen estate is consumed by the variable name is a bit difficult) and has no "dreadful" `except Exception`. Or every mutable class attribute variable is annotated with `typing.ClassVar` (RUF012 - the most idiotic rule I've ever seen). Nevermind that it doesn't really stop anyone from changing value of that attribute. You must annotate it with `ClassVar`!
It's an idiotic cargo-cult.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#124Earlier 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…
> 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
I remember people saying this exact same thing about Python ~20 years ago.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#125The 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 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.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#126Earlier quoted context omitted.
Waiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing
My argument is more to the tune of "everybody’s code looking slightly different is not a problem in practice as long as I can read and understand it." However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as i…
I'd go so far as to argue that person to person differences are helpful to a reader. When I am dealing with a long term code base it's easy to develop a feel for who is responsible for different constructs without needing to rely on the git history. This gives me immediate information on what to expect.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#127The 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…
Dunno, now the workflow is like agent makes code changes, ruff complains, agent fixes complaints at the cost of code bloat, agent makes a PR, another agent reviews the PR, agent makes changes, PR is approved and merged. Nobody reads PRs anymore with the agentic development velocity.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#128Earlier quoted context omitted.
TIL I am divine! By the way, you have the exact energy of someone who would argue about code style: a prima donna who quotes Emerson when confronted with disagreement.
You can build yourself any strawman you want :) In my first ten years of writing Python, I never argued about code style with anyone. It's only after they brought the bots in that I learned that my style is somehow "bad."
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.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#129The 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.
Thank you, but I'm afraid I disagree. Single line dict definitions are fine when that's my intent, multilines are also fine when that is, and I trust myself to know when to use one or the other. My problem is with arbitrary rules like "only x-line dict definitions are allowed," for any value of x.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#130The 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.
I'm surprised a formatter does that. Prettier in the JS world likes to jam destructured arguments onto one line, but it will leave them alone if there's a comment.