I'm not a python person (for many years, at least), but I'd choose black for a completely different reason. By using Black, I'm choosing standardization over my whims.

Which, as a longtime Go dev and now Rust dev, I love formatters that are opinionated. I don't always love what Gofmt or Rustfmt do, but I definitely like consistency that the community has in code style.

So I don't care what Black thinks - I care what, hopefully, everyone uses. Though, I could see a situation where formatting can be altered and the project has a format config. Meaning that while code fmt differs between projects, it would be consistent among all devs working on X projects.

Our test pipeline fails any Python service trying to deploy if the black style check fails.

I was initially grumpy about my org adopting black because I preferred single quotes, but the level of standardization is a huge win in my book. I never even think about my code style anymore, I just write it and then run black.

I've always been a double-quoter, in contrast to most Python devs I know/work with. After we standardized on black, I got some satisfaction seeing all of my coworkers bend to my will (/s).

How narrow those two choices are! The correct answer is obviously to use single-quotes for keys and key-like cases and double-quotes for values. Make formatters impossible to write! (last sentence very /s, but that style actually exists)

That actually seems to be the de-facto Python style. Even Guido said at some point that that's his convention.

You can disable string normalization with Black, and then continue using single quotes all day. But then, yeah, you give up enforced standardization on that.

I started out double quoting but it takes longer to type Shift " vs ' so I switched early on.