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

131–140 of 251 posts

Re: Black – Uncompromising Python code formatter

#131

Post by [deleted] »

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…

[deleted]

Re: Black – Uncompromising Python code formatter

#132

Post by hrktb »

CrLf wrote: post #39
skybrian wrote: post #22

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…

I don’t code in python so have no opinion on Black, but most code formatter can be adjusted to exclude some cases of formatting.

I you would be fine with 95% of what it does and just want it to ignore the 5% where you care the most, I think the tool could benefit you.

At least that’s how I feel about autoformatting in general.

Re: Black – Uncompromising Python code formatter

#133

Post by ebg13 »

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 write code like that, because lumping brackets together absolutely makes it harder to see what they are.

Re: Black – Uncompromising Python code formatter

#134

Post by neuronexmachina »

My current "problem" with Black is actually a 5-year-old bug in how pylint checks for bad-continuation issues with hanging indentation. Sure, you can ignore the pylint rule, but I imagine pretty much everybody who tries to use black and pylint on the same codebase runs into this issue:

* https://github.com/PyCQA/pylint/issues/289

* https://github.com/python/black/issues/48

Re: Black – Uncompromising Python code formatter

#136

Post by lucaspottersky »

abtinf wrote: post #82
hardwaregeek wrote: post #7

This is a case where I'm completely decided. Everybody should use an autoformatter. The minimal benefit you get from custom formatting is completely outweighed by the uniformity, the consistency and readability of autoformatted code.

I think a nontrivial portion of Go’s success can be attributed to having a standard format and treating deviation as compiler errors. It is immensely valuable to be able to look at any Go code, whether in the toolchain, the standard library, or a random stackoverflow snippet, and not have to think about formatting at all.

thats actually a very annoying feature that has thrown me off when i tried.

you can't even comment out your code while debugging. annoying as hell.

Re: Black – Uncompromising Python code formatter

#137

Post by setr »

tedmiston wrote: post #59
rav wrote: post #43

Earlier quoted context omitted.

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.

Every metatool you use does that - syntax highlighting, linters, formatters, ide’s, etc

You always end up adapting to the tool, while adapting the tool to you

Until you oneday reach a perfect harmony with your tool... until you introduce another one, and the equilibrium must once again be found.

Also of note, this is a general principle/behavior (eg you and your furniture..!)

Re: Black – Uncompromising Python code formatter

#138

Post by fjp »

asdkhadsj wrote: post #85
tedmiston wrote: post #57

Earlier quoted context omitted.

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.

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…

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.

Re: Black – Uncompromising Python code formatter

#140

Post by pritambaral »

crooked-v wrote: post #135
davidjhall wrote: post #98

Why on earth would it convert this: printable_chars = { 33, 34, 35 [...and another few hundred ] to printable_chars = { 33, 34, 35 [...and another few hundred lines ]

Those look the same to me.

Perhaps your parent failed to add double-newlines and HN's formatting ate their newlines, but notice the extra word "lines" at the end.
Post reply on HN