Live data from Hacker News

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

astral.sh

201–210 of 247 posts

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

#201
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 actual problems in the code I work with are not the spaces at the end of line or imports in non-alphabetic order, it's the 10-line list comprehensions that are so long that they're impossible for me to parse. 100%. Almost all of my time burned navigating code is not hung up on stylistic conventions but on nasty services with inconsistent abstractions and patterns. BUT, conventions and consistency make code easi…

> it's the 10-line list comprehensions

I feel for you both working with straw men day to day. I’ve worked mainly in Python for two decades and have neither seen such a thing nor considered, even to be a bastard, doing such a thing.

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

#202
post #162

Earlier quoted context omitted.

your argument is about formatting and clearly you feel strongly about it. this is the difference between the atheist who strongly believes nobody should believe and the atheist who isn't interested and doesn't care

Yeah, I'm in the "not interested" and "don't care" camp, with the addition of "please don't come at me with your bots who would tell me what to believe and what not to believe". If someone wants to use a linter, I have no problem with that. I don't, and I don't want others forcing one on me, especially so as most of its "results" are straight in "this doesn't matter either way" category (in my example: two spaces ins…

I think, generally speaking, the decision to enforce a linter in CI/CD pipelines is well within a project lead’s or technical director’s purview, and there seems to be a pretty broad consensus that they add value, so they’ll almost always be in CI/CD pipelines. So just use the same linter locally and format on save so you catch any issues like your comment getting folded example.

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

#203
TIL RustPython uses Ruff's AST which is fast.

LibCST can modify the AST/CST to do python codemod, now in Rust too;

rustpython-ruff_python_parser: https://crates.io/crates/rustpython-ruff_python_parser .. https://github.com/astral-sh/ruff

LibCST: https://github.com/Instagram/LibCST

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

#204
post #143

Earlier quoted context omitted.

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 t…

You neither usually write in that style, nor go full shrink mode on people you talk to, so your original comment here is quite unusual in both the contents and the style.

Peace, man.

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

#205
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
  -}
  +no_comma = {"x": 3, "y": 42, "z": 2}
  
  with_comma = {
       "x": 3,
  @@ -12,6 +8,6 @@
  
  comment = {
       "x": 3,
  -    "y": 42, # Answer to the Ultimate Question!
  -    "z": 2
  +    "y": 42,  # Answer to the Ultimate Question!
  +    "z": 2,
   }
  
  1 file would be reformatted
(I intentionally switched to double quotes since that really is a stylistic choice in Python, you can escape in both, and if you use double quotes inside of single quotes ruff leaves it as-is)

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

#206
post #95

Earlier quoted context omitted.

Oh, absolutely. I started writing Python professionally in 2010. Whenever a new group of people started working on a Python project, one of the first things they had to decide was tabs versus spaces. Everyone would begin by saying that the question was unimportant and silly, but then immediately add a “but” followed by a detailed justification of their personal preference. That would lead to people spending two full…

I think that tabs vs spaces is a rather extreme example because it has unexpected parser semantics - that is, it's not a style choice. So I don't think it's actually relevant to a conversation about conventions/ style.

It definitely is relevant to a discussion about linters. And as I said on my comment - it's just an example, I mentioned other types of discussions as well.

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

#207
post #157
post #146

Earlier quoted context omitted.

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

Why though? I've yet to come across an auto formatter that formats things the way I personally like. But that's fine. I do whatever the hell I want until I'm ready to open a PR, then bang it through the auto formatter. And you know what? I can also go the other direction and run a home-brew auto formatter to reshape things the way I personally want on my local machine.

I'm not sure why, but apparently my experience is unwelcome enough to be downvoted. Drive by changes are really annoying, IMO, and as the GP shows, the formatting tool outcome differs. So there are many "valid" versions of the same program logic. You have therefore not do what these formatters pretend to do, namely take this variable out of the equation. Rather, the wrong auto format can look much worse than the original.

I'm not sure why people felt formatters were necessary. but now they're part of the zeitgeist and there is no going back.

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

#208
post #200
post #191

Earlier quoted context omitted.

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…

The options you suggest seem to be either (a) feed the bot now (halt development and reformat all code) or (b) under-pin/suppress and feed the bot later, probably dealing with people adding more non-conformant code to already-reformatted files.

You will probably have to do it all over again when these guys release even newer and shinier 0.17.0, with even more rules.

I can't understand how the option of not feeding the bot eludes people.

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

#209
post #113

Earlier quoted context omitted.

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.

Please don't turn this site into Reddit.

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

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

Ruff/black support and enforce this. Just do ‘'z': 2,’

If you add an extra dangling comma at the end of the last item, ruff/black will auto-format to the line-by-line style you like.

Post reply on HN