Hacker News

Tbh I was super enthusiastic about Ty but it’s just so far behind basedpyright I had to switch off it. The lack of checks wasn’t the issue, it was the false positives which were the real dealbreaker. That and it doesn’t have support for baselining, which is such an insanely awesome feature for larger codebases. uv and ruff are incredible though. Maybe someday on Ty.

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 linting as it's good enough with automated tools.

I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.

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'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 discussion. The sum of which is: linters sometimes make changes to code that I don't like.

I'd encourage you to reconsider what's really important when it comes to team development and try listening more to those around you. You seem overly focused on asserting your opinion instead of having a discussion.

These types of exchanges are usually very unproductive and stressful in a team environment. They are evidence, IMO, of a dev having the wrong priorities. I'd encourage you to step back and really consider how you view craftsmanship in a team dynamic and whether or not you are fighting the right battles.

It’s because you forgot a comma after the last item. If you had kept that the items wouldn’t have been compacted (at least in black, I’ve stopped linking my code because it breaks intends of formatting more often than it helps)

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.

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 sure I understand the “ My place used pylint, flake8, black, ruff -- with hundreds of commits on every change”. These tools don’t add extra commits. You run them prior to your PR, get them aligned with the linting, and then commit the change you were already going to make. Thats 0 extra commits.

For someone ultimately arguing that there is too much effort spent on people’s coding styles, you are spending a lot of effort arguing about people’s coding styles. These tools are some of the most set it and forget it things around.

> 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 easier to read and write, period. If you’re debating over single or double quotes that’s almost a fireable offense IMO.

Additionally, when you have a culture that delegates to tools as much as possible, the focus sharpens in a healthy way.

Stylistically ugly code that is globally consistent (ideally across the entire ecosystem) >> locally beautiful code that is inconsistent with the rest of the codebase / up to authors taste. No one likes black formatting, but it’s at least consistent. “Your car can be any color you like as long as it’s black”

With regards to your example, adding a comma to the final element should preserve multi-line. You just don’t know the formatting rules yet apparently

The actual rules are less important, only the consistency of applying them is.

I find that people who argue against automatic linting and formatting tend to be the same that would argue incessantly about style. So much wasted energy, I want none of that.

Also, in your example above, if you put the comment on the line _above_ instead of inline the formatter will most likely do the right thing.

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

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.

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.

Oh man, list comprehensions, that's me. I get inspired, caught up in the flow, write some eldritch horror of a LC. 30 seconds later "What in the name of saint Lovecraft does this even do?" (sighs) Rewrite as a loop. I mean, I guess they are fine in small doses, very small doses, But boy do they read poorly compared to the rest of Python.

I also need something to save me from my regexps, the verbose flag helps a lot. but what would be really nice is some sort of python subset that could compile to the state machine. I would also like composable expressions, that is, composable at the graph level not the string composition we are forced to use. And a pony, I would also like a pony.

As you can tell I am not a fan of APL, not because of what it can do but because of the super compressed syntax it adopts. see also: perl

Put a comma after "'z': 2" and it will work how you expect, fyi

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.

Yes sure, but the point of something like ruff is that you don't even think about formatting anymore. It is just done for you and it is done consistently.

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

It's funny to see this comment about Python, which was designed to be a style North Korea. Maybe in a decade we'll see a Go linter and have a good laugh at that.

The "bad" code is actually bad imho. The comment explains intent inside the object rather than on the spec, which makes it easy to miss and harder to discover later.

This seems like a case where the tooling is compensating for unclear conventions. Collaboration tools are useful, but it may be more effective to strengthen the code specifications and documentation practices first, so intent lives in a predictable place instead of being scattered through implementation details.

It does and it is even better. It is called the Go Analysis Framework (https://pkg.go.dev/golang.org/x/tools/go/analysis).

It is fairly new so not well known but it is what powers go fix and go vet under the hood. And I believe the Go team is currently working on making it possible for module authors to easily describe their own custom analysis passes that would run automatically when running go fix.

It is extremely easy to define your own analysis.Analyzer struct that describes your own static analysis pass. You get access to all sorts of useful information such as the AST, types, even SSA info and you can even compose the information between analyzers. Then you can easily compile it into a binary and run it by passing that binary to go fix with a command line flag. The go toolchain itself handles all the complex caching logic so that your analyzers run fast.

Since it is made by the go team itself and part of the toolchain it should slowly become the unified standard you are looking for. So hopefully golangci-lint and others should eventually all unify under this framework.

You can easily give it a go by telling some AI agent to write some Go Analysis analyzers and telling them to drive them with go fix. My Go projects tend to accumulate a bunch of these to enforce all sorts of rules deterministically and automatically instead of some imprecise markdown file.

Oh wow, not so long ago the sentiment was exactly opposite. Python community was struggling with tools and everyone wished to have `gofmt` for Python.

Granted, this is a linter, not a formatter, but my larger point is I am glad that Python ecosystem evolved like it did recently.

I’m not entirely sure what you mean by a fragmented ecosystem? Go has first-party formatting and linting and the language is deliberately restricted to ensure it is written in a certain way, even when written by complete novices.

Compare that to Python or TypeScript which are Wild West languages without opinionated first-party tooling, and it’s clear why Ruff/Biome feel great.

You just wouldn’t get that same high with Go.

What? I feel go has one of the best language tooling out there without requiring a bully ide to do stuff. golangci-lint is quite comprehensive. What do you miss otherwise?

(Honestly go's distributing itself has covered a lot of it)

Golang-ci exists for a while and everyone is using it.

Not sure what you're talking about.

Maybe it's just me, but getting overrun with "413 x potential warnings" hardly sounds useful :) Great for greenfield, less so for existing projects. Although nowadays, fire up your agent with "/goal work through and address all lint warnings by fixing the code according to XYZ" and leave it alone for a couple of hours and I guess it's no longer an issue...

Don't get me wrong, the new level of details coming from Ruff is much appreciated and a good thing :)

> 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

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.

100% agree, I am upgrading my projects now. And yet, I have mixed feelings about this. I like to think that when I (was) writing code myself, I applied a great deal of intuition to decide when to skip or ignore some rule. On the hand, I also saw projects were developers where using pylint with most rules enabled and I have to say the code was not better - on the contrary it had plenty of hacks to make pylint happy at the cost of illegible code.

Not unlike that experience, I also saw coding agents spend lots of tokens trying to fix a benign issue, as well as doing the opposite - like disabling the tests !!! when they don't pass. :facepalm:

I grew to trust AI results in terms of overall correctness, but I still have hard time trusting their *judgement* on the *code quality*.

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.

Why must my poor semver be hurt so!

It is fully according to their versioning policy:

https://docs.astral.sh/ruff/versioning/

But also compliant with semver:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/

(Maybe I misinterpreted your remark, but semver does not get hurt.)

It's conventional for semver to allow breaking changes for 0.x minor releases (but not for patch releases).

Zerover for life

What languages are python interpreters written in?

Interesting but not surprising in an application where speed matters.

It's the same for JavaScript. Rust is the better language (especially for large projects like these), but sometimes you don't have a choice but to use Python or JS/TS.

Wait until you hear what CPython is written in.

Broadly you have a point. In this case I would expect a Rust-based Python linter to run significantly faster than one writen in Python itself (e.g., pylint).

ruff is not new. It's also truly really fast. On an as-yet un-ruff'ed 32k SLOC python package it returns in 158ms finding 2k errors. Having it fix errors is also very fast.

What's really tiring is reading such facile "critiques", especially when they are not even applicable.

Compare it to some of the other options in that space and you'll see why that was a selling point.