why?
Do you hate terse diffs in git?
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!!
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.
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.
