I love it even though I dislike quite a few of its formatting rules.

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.

Rob Pike's proverbs about Go fmt springs to mind: "Go fmt's style is nobody's favourite, but go fmt is everybody's favourite."

gofmt, on the other hand, gives you a lot more flexibility to wrap lines how you deem appropriate. I like gofmt way more than black.

Exactly, gofmt is actually almost perfect. Ironically, it makes Rob's quote less meaningful.

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.

Word. I got major pushback trying to fix this problem at my last company, which is (in part) why I'm not there.

Yup! This.

Before I introduced Black in my workplace, all code reviews were peppered with stuff like "should be indented", "use single quotes" etc. Made it impossible to talk about the stuff that actually matters.

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.

Agreed. My only grievance with Black was that it was really slow compared to gofmt or rustfmt, but that’s a perennial problem with Python tooling.

This is now improved. Black is compiled with mypyc, should be roughly 2X faster than before.

Oh, good to know!

Is there a way to pass hooks with a repo, or do you have to give people instructions about how to install them and hope they do it?

Not directly, unfortunately. Sometimes you can hook it into the tooling, like the Makefile or the test runner.

Other than that, enforce it in CI: patches that don’t match the code style can’t be merged

Here here! Same.

NB: It’s “Hear, hear”, not “Here, here”.

Thanks mate.

The problem I have with it is that, to me, these are super readable:

    x = [ 1, 2, 3 ]
    y = { 'a': 1, 'b': 2 }

Whereas these are not:

    x = [1, 2, 3]
    y = {'a': 1, 'b': 2}

To me, declaring inline lists and dicts without the leading and trailing space makes it more difficult to see what the data structure is, and what it contains. This is especially true when you have lists or dicts declared inline as arguments to functions, e.g.:

    my_function_call([ 1, 2, 3 ])

versus:

    my_function_call([1, 2, 3])

While it's generally not good style to declare data structures inside function calls, at least with the space it's still somewhat apparent what's happening, whereas without the space it just looks like three positional arguments. I love the idea of black, but in practice I'm not going to use something that changes my own code into something that's more difficult for me to read.

That’s gotta be a really unpopular opinion since I’ve never seen anyone write “[ 1, 2, 3 ]” instead of “[1, 2, 3]” in the last 10 years or so.

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.

I've recently been working with an old C++ codebase that formats every function call like this:

  Foo<Bar,Baz> value = some.method (1, 2, 3 + 4) ;
  // or with no parameters:
  value = some.method() ;

I've never seen it anywhere else, and it took me a good week to get used to it.

You might not have been writing JavaScript. For objects, spacing properties from curly brackets is pretty much the norm, Prettier does that by default. For lists I see it rarer but I personally use it instinctively for consistency with objects, especially with things like useState destructuring and ([ complex, ...splatting, ...combinations ]) into function calls (which admittedly becomes uncomfortably terse).

And here’re some fresh examples with lists just encountered in the wild: https://developer.matomo.org/guides/tracking-javascript-guid...

FWIW, I do "[ 1,2,3 ]". So we exist, perhaps you just haven't bumped into us :-)

My only response to this would be “get used to it”.

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.

Agreed - end of day, code formatting is not that important in the context of how end users utilize the product.

Read a lot of different code and programming languages. They all look pretty much the same after awhile, formatting and syntax.

I think it just doesn't matter anymore because almost all editors support code folding and visual markers for it, making it MUCH easier regardless of 2 vs. 4.

> 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.

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.

And that’s the reason everyone should use tabs. You like 2, I like 4, someone else one the team likes 3, 6, 8, whatever? No problem if tabs are used, everyone can set tabstop to their liking!

Just learn how to make them readable. I am yet to see a single developer who didn’t manage to learn that. Seriously, the worst types are the ones who think they are experienced enough to think what “is more readable”. It’s all a matter of habit.

I disagree: your style is less readable than Black's. You've moved the data-structure syntax away from the data, and toward the function-call syntax, causing them to blend together.

This would be more readable -- put the space around the structure, not inside it:

    my_function_call( [1, 2, 3] )

Now we can clearly see the separation of the argument from the function call. But I wouldn't bother switching code formatters just to have this.