[IshKebab]

What's the alternative? YAPF is even worse - it will flip flop between styles even on the same version! Its output is much less attractive, and there are even some files we had to whitelist because it never finishes formatting them (Black worked fine on the same files).

Not using a formatter at all is clearly worse than either option.

[bombolo]

> Not using a formatter at all is clearly worse than either option.

why?

Do you hate terse diffs in git?

[IshKebab]

Because some people are really bad at formatting code manually and constantly nitpicking them about it is both tedious and antagonistic. Its much better for a faceless tool to just remove formatting from the equation entirely.

I think the sane part of the software engineering world has realised that auto-formatting is just the right way to do it, and the people that disagree just haven't figured out that they're wrong yet.

Maybe you meant "why is Black specifically better than no autoformatting, given that it isn't perfectly stable across versions?" in which case the answer is:

a) In practice it is very stable. Minor changes are easily worth the benefits.

b) They have a stability guarantee of one calendar year which seems reasonable: https://black.readthedocs.io/en/stable/the_black_code_style/...

c) You can pin the version!!

[bombolo]

> the people that disagree just haven't figured out that they're wrong yet.

This is unnecessarily confrontational. Please read my other comments where I consider the extra effort that automatic formatting causes for code reviews.

> In practice it is very stable.

It has never happened to me to upgrade black and have it not change opinion about black formatted code.

> Minor changes are easily worth the benefits.

It doesn't matter how minor they are. A 1 bit difference is still going to fail my CI.

> You can pin the version!!

I usually do, but working with old releases that must be maintained, mean that I can't cherry pick bug fixes from one branch to the other, because black fails my CI.

[IshKebab]

> I consider the extra effort that automatic formatting causes for code reviews.

Why would it cause extra effort? Not having automatic formatting causes extra effort because you have to tell people to fix their formatting!

> It has never happened to me to upgrade black and have it not change opinion about black formatted code.

I'm sure small things change but large differences? No way. Even the differences between YAPF and Black aren't that big in most cases.

> It doesn't matter how minor they are. A 1 bit difference is still going to fail my CI.

Right but you have a pre-push hook to format the code using the same version of Black as is used in CI. Then CI won't ever fail.

> I can't cherry pick bug fixes from one branch to the other, because black fails my CI.

Cherry pick, then run Black. Sounds like you have a very awkward workflow to be honest.

[bombolo]

> Why would it cause extra effort?

As I said… because a 1 word change easily ends up changing multiple lines and from the diff it's not clear it's just a 1 word change. So… extra effort.

> Right but you have a pre-push hook to format the code using the same version of Black as is used in CI. Then CI won't ever fail.

No I don't. My release branch and old-release branch use different versions. Such a thing would need to understand which base branch I'm working on, or recreate the venv continuously.

> Cherry pick, then run Black. Sounds like you have a very awkward workflow to be honest.

Seems to me you don't support older versions, in which case everything is easy.