Because the only thing worse than a slightly wonk formatting convention is spending any time at all implementing, arguing about, or otherwise worrying about formatting conventions.
I think gofmt's brilliance comes down to it not being overly pedantic, it doesn't have an opinion on how all code should be formatted, it only fixes what it sees as clear mistakes.
When introducing it there was some resistance. There's always that one guy who tried it once and it reformatted that perfectly hand-formatted function. My answer to them was suck it up. In a tiny fraction of cases Black might make a suboptimal choice, but the rest of your code is so shit it outweighs this negative by 100x.
Other than that, enforce it in CI: patches that don’t match the code style can’t be merged
x = [ 1, 2, 3 ]
y = { 'a': 1, 'b': 2 }
x = [1, 2, 3]
y = {'a': 1, 'b': 2}
my_function_call([ 1, 2, 3 ])
my_function_call([1, 2, 3])
I used to think 2 space tabs made code harder to read than 4. Now I used 2 spaces and I’ve gotten used to it and can read it fine. And I have no doubt you could learn to read the black formatted code just as easily. I can, since that is how I format my code anyway.
Read a lot of different code and programming languages. They all look pretty much the same after awhile, formatting and syntax.
I might be in the minority, but it's an empirically testable proposition. Given the thousands of people taking Python quizzes for toptal, triplebyte, etc., it should be possible to see which version results in a lower time to answer or a higher accuracy rate.
If anything I’m seeing the opposite trend with a few devs writing “[1,2,3]” so that large constant literals don’t overflow the line.
Foo<Bar,Baz> value = some.method (1, 2, 3 + 4) ;
// or with no parameters:
value = some.method() ;
This would be more readable -- put the space around the structure, not inside it:
my_function_call( [1, 2, 3] )