Live data from Hacker News

Black – Uncompromising Python code formatter

github.com

71–80 of 251 posts

Re: Black – Uncompromising Python code formatter

#71
post #61
post #44

Earlier quoted context omitted.

> Having a standard is more important than the standard being excellent. Neither is very important, though. It's just formatting and your code will run the same regardless.

You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.

Why use many word when few word do trick

Re: Black – Uncompromising Python code formatter

#72

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

> Having a standard is more important...

Let me take a shot at why it's important.

We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations.

We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals.

An auto-formatter removes a ton of deviations that don't matter, and desocializes the aesthetics.

This saves code reviewers time and stress and helps them focus on what actually matters in the code.

And it only has to save more time than it takes to run "pipenv run black" to be measurably worth it.

Re: Black – Uncompromising Python code formatter

#73
post #39

Earlier quoted context omitted.

Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.

No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple…

why not use their ```# fmt: off``` ?

I have not used Black, but considering it so I am curious about these occasional situations where you want to override auto-formatting

Re: Black – Uncompromising Python code formatter

#74

I've been using this for a couple of weeks and its a been really nice to remove the constant mental overhead of structuring code. it also makes you think about structuring functional blocks into more manageable, bite-sized chunks which is easier to understand. 10/10 would recommend

Yes, the side effect of using black seems to be a more reasonable factoring within function bodies.

Re: Black – Uncompromising Python code formatter

#75
post #44

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

> Having a standard is more important than the standard being excellent. Neither is very important, though. It's just formatting and your code will run the same regardless.

A kindred spirit.

I've never been able to wrap my head around people having strong opinions on style issues. I'll defer to whoever cares the most on the team and then just do that. When I look at the problems in code bases, rarely has "slightly inconsistent formatting" been at the top of the list.

Re: Black – Uncompromising Python code formatter

#76
Black is amazing. I've added it to all my work projects and will be adding it to all my personal projects over time. My own opinion is that black is the future of Python formatting and it's a long time in coming. I disagree with many of the ways it formats things, but I mostly am just ecstatic to no longer have to discuss these things and just write code. If you are an isort user: isort's primarily goal for the next release is to add a mode that gaurentee's 100% compatibility with black (it can be achieved currently via config options). And of course, I'll be formatting the isort project itself using both isort and Black.

Re: Black – Uncompromising Python code formatter

#77
post #71
post #61

Earlier quoted context omitted.

You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.

Why use many word when few word do trick

Yeh y ndeed

Re: Black – Uncompromising Python code formatter

#78
post #72

I often dislike autoformatter output too, but then I remember that while no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code, and then I chill out about it. Having a standard is more important than the standard being excellent.

> Having a standard is more important... Let me take a shot at why it's important. We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations. We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals. An auto-formatter remov…

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

Re: Black – Uncompromising Python code formatter

#79
post #61
post #44

Earlier quoted context omitted.

> Having a standard is more important than the standard being excellent. Neither is very important, though. It's just formatting and your code will run the same regardless.

You could say that about anything, though. Why use punctuation and capitalization when typing forum comments? Its just syntax after all.

No, that's a completely invalid objection. Punctuation in natural languages isn't just aesthetic, it changes meaning.

Re: Black – Uncompromising Python code formatter

#80
post #28

Against my better judgment I'll bite. I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings". Here's a small example: basket.add({ apple.stem for satchel in satchels for apple in satchel }) Black formats this as: basket.add( { apple.stem for satchel in satchels…

That one actually makes a lot of sense to me, even if I've got to admit that I tend to go with the first option in my own code. It looks to me like a result of a couple rules that, in general, are sound: First, if an argument list can't fit all on one line, then every argument needs to go on a new line. And all the arguments need to be indented to the same level. The argument to that function includes the braces, so the opening one needs to go on a new line, and the closing one needs to be indented as well.

In this particular case, that may result in code that breaks with tradition. But I can't see a way to preserve the tradition without creating special or edge cases. For example, we can't follow the first option and get clean formatting with a function like zip. You'll have a train wreck of bad options about where to put the braces and how to place the comprehension's body in relation to the braces that enclose it. Versus, with Black's style, the answer is easy and straightforward, because you just do it the same way you would anywhere else:

  zipped = zip(
      {
          apple.stem
          for satchel in satchels
          for apple in satchel
      },
      {
          apple.core
          for satchel in satchels
          for apple in satchel
      }
  )
IMO, that's good, even if it isn't what we're all used to. Having a bunch of special cases just to match what someone might think is more aesthetically pleasing in specific situations is not a desirable feature in a set of autoformatting rules.
Post reply on HN