Live data from Hacker News

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

astral.sh

171–180 of 247 posts

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

#171
post #95

Earlier quoted context omitted.

At work? School isn't really representative.

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…

> only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces.

yeah, why Guido got away with the "we don't need deliminators, white space is just fine" for so long has always baffled me.

Because somehow a special character that marks the start and end of a block is hard for people to understand??

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

#172
post #112

Earlier quoted context omitted.

The one day, your chef leaves, the food goes to shit and productivity/output/morale drops. When the new chef arrives, then everyone has to relearn everything. Software shouldn't be bespoke and "artisan".

And here's where this abstraction breaks: when a programmer leaves, their code is not going anywhere. The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

I too want to be an artist, but I work in an economy that requires me to be an artist mostly in my off hours.

And honestly, this is such a weird hill to die on. Lint rules when automated are basically pure win in most scenarios, and for your example, just exclude the rule for this block.

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

#173
post #152

Earlier quoted context omitted.

That's an uncharitable take and I urge you to reconsider. I also take great joy and pride in the art of writing beautiful code. I have no desire to be a cog in a machine. However, my ADHD brain is delighted to not have to make a million little distracting decisions in place of the code planning I should be doing. Formatters let me concentrate on writing the best data structures and APIs and algorithms instead of how…

The beauty of it is that all artists can be different. It's the cog wheels that need to be identical.

I genuinely think you're on the wrong track there. Someone can express their artistry different from your ways and still take pride in their artistry.

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

#174
post #64

Earlier quoted context omitted.

Sorry, but I did not "forg[e]t a comma after the last item". I intentionally did not put a comma there. The list of the "important numbers" in my example is already complete and perfect, and is not supposed to ever change. I wanted to emphasise this fact by specifically omitting the comma there, in the hope that intelligent people in the future would get this message exactly as I intended for it to be.

The trailing comma rule is to avoid errors when devs copy/paste a line or dump a new line at the end. This matters particularly for arrays in languages with implicit string concatenation, where the missing comma won't trigger a compile error.

yes, and isn't it funny that

foo=[baz, bar,]

returns a nice list of two items, but if you edit this down and miss the comma,

foo=bar,

is not a scalar.

returning a tuple.

So the trailing comma thing is a thing.

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

#175

Earlier quoted context omitted.

> this seems like a made up problem or something that predates my career I can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.

What is "back in the day" here? I've been in this field for like 16 years.

Others may remember it differently, but I feel like things started to change somewhere between 2009 to 2012? People were still hand-indenting code back then, and your personal style felt like something you had a bit of ownership of or was a creative outlet for you. I think we are in a much better place now where the editor + a central config file owns the whole thing, and I'd be surprised to see a modern codebase where a formatter's defaults weren't being used.

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

#176
post #44

I updated a ~3k line Python project with this the other day. I was using v0.15.x beforehand. It didn't take too long and the new rules do improve code quality. It caught quite a few things previous versions didn't. Here's a few commits of changes: (A whole bunch of manual changes based on its suggestions) https://github.com/nickjj/plutus/commit/9af66d31f98bef841588... (Re-enable line length) https://github.com/nickjj…

[flagged]

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

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

There is no point discussing these minutia, ever. Just ban discussing them in PRs and then you don't need an opinionated bot rife with false positives to "fix" them.

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

#178
post #44

I updated a ~3k line Python project with this the other day. I was using v0.15.x beforehand. It didn't take too long and the new rules do improve code quality. It caught quite a few things previous versions didn't. Here's a few commits of changes: (A whole bunch of manual changes based on its suggestions) https://github.com/nickjj/plutus/commit/9af66d31f98bef841588... (Re-enable line length) https://github.com/nickjj…

[flagged]

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

#179

Earlier quoted context omitted.

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

On problem of such go linters is they can only lint what the compiler sees so if you have multiple `build` tags, you need to run multiple lint passes. No other language's linter operates like they, they all operate on file level.

[deleted]

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

#180
post #47
post #26

Earlier quoted context omitted.

Go has a good start for that, but It's not enough for me. Gofmt is a great idea but it isn't strict enough for my taste. Go does not have any first party static analyzers, closest is Staticcheck which is even sponsored by Google themselves

go vet, plus all the ones in gopls?

[deleted]
Post reply on HN