[codingkev]

A little shoutout to a alternative Python formating tool https://github.com/google/yapf (developed by Google).

The built in "facebook style" formating felt by far the most natural to me with the out of the box settings and no extra config.

[timhh]

I did a blind survey of YAPF vs Black at my work. The results came back as 70% in favour of Black.

Black gives generally nicer output, and also more predictable output because its folding algorithm is simpler. YAPF uses a global optimisation which makes it make very strange decisions sometimes. Black does too, but much less often.

There are also non-style problems with YAPF. It occasionally fails to produce stable output, i.e. yapf(yapf(x)) != yapf(x). In some cases it never stabilises - flip flopping between alternatives forever!

Finally it seems to have very bad worst case performance. On some long files it takes so long that we have to exclude them from formatting. Black has no issue.

In conclusion, don't use YAPF! Black is better in almost every way!

[VectorLock]

How did you perform the blind survey? Format some code with Black and YAPF and ask people which they liked better?

[timhh]

Yeah exactly. I had 20 samples from our codebase that showed some representative differences and you had to click on which one you liked more. The order (Black/YAPF or YAPF/Black) was randomised.

I also had to turn off Black's quote normalisation otherwise it is really obvious which is which. Quote normalisation is another point in Black's favour.

I could put the survey up somewhere if anyone is interested.

[lelandbatey]

YAPF is slower than Black for many degenerate cases, a fact I notice most strongly since I use an "auto-format file on file save" extension in my editor. The case I found in particular was editing large JSON schema definitions in Python, as they're represented as deeply nested dictionaries. Black seems to format them in linear time based on the number of bytes in the file, while YAPF seems to get exponentially slower based on the complexity of the hard-coded data structure. It was a niche case, and the maximum slowdown was only ~1-2 seconds, but that editing freeze was quite annoying.

[BiteCode_dev]

yapf is configurable, and that's why it never won.

[crad]

What's wrong with configurable? Too much opportunity to bikeshed?

I figured yapf was not "new" which is why black won.

Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community.

Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to reinvent the wheel.

[BiteCode_dev]

There is no "best format". It's a matter of opinion.

Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure.

Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a ticket and complain. And after while, you do it again, because the debate is never settle even in the same team or project.

There is not way to take a team of 3 people, choose a style, and make it so that they are all 100% happy with it.

Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.

People realize the cost was not worth the satisfaction, which you are unlikely to get anyway. Let's just move on to what matters, it's good enough. Pareto.

[eredengrin]

> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration

Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and live with it forever, that's how those teams work.)

> Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.

I don't see how this follows, if a team was dysfunctional enough to be wasting hours and hours of time before, I can't imagine why that wouldn't continue. It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options".

[BiteCode_dev]

> Sounds like a team problem,

You had a good team. I had a great mum. Some people have great doctors.

> It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options".

If the practice doesn't match the theory, I'd rather trust the practice.

[eredengrin]

Well if it helps your team out then that's great, I just wouldn't expect that to generalize well. But who knows, people are weird, maybe more would give up fighting about style because of a tool change than I expect.

[BeetleB]

All problems are team problems. It's OK to use technical solutions to get around them.

[stavros]

> Too much opportunity to bikeshed?

Yes, and also too hard to set up. It's extremely dumb, but I'm much more likely to use something I can't configure, because if I can configure it, I'm going to want to, and it'll take forever to make all those choices.

[crad]

I've never had to configure yapf, even though I could...

"yapf -i --style=pep8" works great.