Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black – Uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

51–60 of 251 posts

Re: Black – Uncompromising Python code formatter

#52

Post by ixtli »

inglor wrote: post #37

And in Stack Exchange's "The Workplace", people are complaining that their employees strongly object to Black https://workplace.stackexchange.com/questions/136742/virulen...

I have some issues with aesthetic decisions used in Black but the degree of head-nodding on the top answer in the SE post you linked is really disconcerting. The person basically says "well you're the boss so you should kindly remind your employees that its your way or the highway" in several different sentences.

It's pretty disturbing that people think this is how a manager behaves. Turns out there are reasons beyond aesthetics that people should apply strict code formatting practices.

Re: Black – Uncompromising Python code formatter

#54

Post by genmon »

I love black: formatting isn't a _big_ thing to think about, but it's always there. Until black. For [current project] it's hooked into VS Code as the default formatter, and (inspired by simonw) we've incorporated a black check into the test suite. It's simple:

https://github.com/simonw/sqlite-utils/blob/master/tests/tes...

Re: Black – Uncompromising Python code formatter

#55

Post by [deleted] »

amelius wrote: post #44
cjbprime wrote: post #35

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.

[deleted]

Re: Black – Uncompromising Python code formatter

#56

Post by jupp0r »

> Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

I run into this philosophical debate at work. In my mind, I don't care much what the resulting code looks like as long as

- it's somewhere in the reasonable spectrum of readablility

- it's consistent and unambiguous

- it never fails for a syntactically valid source file (if it's doing something for syntactically invalid source files, even better, formatting helps me find the error)

There are other opinions though that emphasize minimizing diffs or extensive customization to fit somebody's favorite style (I'm looking at you, rustfmt). Black seems to be right down my alley.

Re: Black – Uncompromising Python code formatter

#57

Post by tedmiston »

camgunz wrote: 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…

I think that's why it self-describes as an opinionated formatter vs YAPF where one has very granular control.

My understanding is that by using Black you're saying I choose to not express my opinions about formatting aesthetics and delegate that decision to Black instead.

Re: Black – Uncompromising Python code formatter

#58

Post by switch007 »

camgunz wrote: 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…

> Black formats this as:

To be clear though, in your example, it would format it as:

  basket.add({apple.stem for satchel in satchels for apple in satchel})
It might also format it as

  basket.add(
      {apple.stem for satchel in satchels for apple in satchel}
  )
It only formats like your example if the statement is much further indented I believe

Re: Black – Uncompromising Python code formatter

#59

Post by tedmiston »

rav wrote: post #43
camgunz wrote: 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…

I completely agree that black does not format all examples in a nice manner, and your example is something I see pretty often. Whenever black adds too many indentation levels and line breaks in what should be a simple-enough statement, I simply refactor into multiple statements, e.g. stems = { apple.stem for satchel in satchels for apple in satchel } basket.add(stems) I concede that without black it wouldn't have mad…

It's an interesting meta thought that using the autoformatter changes the way you write your code. Not that that's implicitly a good or a bad thing, I just find it interesting.
Post reply on HN