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

211–220 of 251 posts

Re: Black – Uncompromising Python code formatter

#211

Post by colatkinson »

bunderbunder wrote: post #89
plorkyeran wrote: post #66

Earlier quoted context omitted.

I don't universally love what autoformatters do to code my coworkers wrote. I've worked with plenty of people who manage to do fewer weird formatting things than what mediocre autoformatters do.

My sense is that configurable autoformatters are doomed to suck. Because an autoformatter with 10 simple yes/no options has 1024 different ways those options can interact, and an autoformatter with 20 yes/no options has 1,048,576 different ways that they can interact. It's simply not possible to make sure that you're going to get reliably good results in the face of that kind of combinatorial explosion. Versus, if th…

This isn't really the case, though. Lots of options are completely orthogonal (e.g. tabs vs spaces and function brace style don't really affect each other). My experience with clang-format has been that each option (mostly) only affects a single token type, which is determined using clang as a backend. I've only seen satisfactory results.

If you don't have as powerful a backend as the full clang paraer/lexer on the other hand, I could quickly see things breaking as you described.

Re: Black – Uncompromising Python code formatter

#212

Post by witten »

fjp wrote: post #138
asdkhadsj wrote: post #85

Earlier quoted context omitted.

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.

You can disable string normalization with Black, and then continue using single quotes all day. But then, yeah, you give up enforced standardization on that.

Re: Black – Uncompromising Python code formatter

#213

Post by arnioxux »

zild3d wrote: post #73
CrLf wrote: post #39

Earlier quoted context omitted.

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

I write a lot of scientific code with python and in those cases you really want your equations and matrix columns aligned for readability. These matrices appear so often adding fmt:off destroys the readability/elegance gain from the clever formatting.

Here's an example snippet by Peter Norvig that is beautifully formatted:

  def neighbors4(point): 
    "The four neighboring squares."
    x, y = point
    return (          (x, y-1),
            (x-1, y),           (x+1, y), 
                      (x, y+1))

  def neighbors8(point): 
    "The eight neighboring squares."
    x, y = point 
    return ((x-1, y-1), (x, y-1), (x+1, y-1),
            (x-1, y),             (x+1, y),
            (x-1, y+1), (x, y+1), (x+1, y+1))

Re: Black – Uncompromising Python code formatter

#214

Post by askvictor »

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.

How do you recommend fitting an autoformatter into a programming workflow? I'm using pycharm

Re: Black – Uncompromising Python code formatter

#215

Post by jordic »

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…

same here! anyway, having a default formatter is awesome!

Re: Black – Uncompromising Python code formatter

#216

Post by jordic »

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…

I'm doing the same :/

Re: Black – Uncompromising Python code formatter

#218

Post by auscompgeek »

JoBrad wrote: post #196
jdmichal wrote: post #188

Earlier quoted context omitted.

OTOH, something like this looks fine also, and is internally consistent with GP's single-block example: zipped = zip({ apple.stem for satchel in satchels for apple in satchel }, { apple.core for satchel in satchels for apple in satchel })

Haven't had the chance to use Python much lately, and immediately thought of how much JS/TS could benefit from comprehensions like this: zipped = {apple.stem: apple.core for satchel in satchels for apple in satchel}

There was a proposal a few years ago to add array comprehensions to the language, but it was ultimately rejected in favour of using .map/.filter instead.

Not sure what came about of object comprehensions though.

Re: Black – Uncompromising Python code formatter

#220

Post by kbd »

detaro wrote: post #180
meowface wrote: post #179

Earlier quoted context omitted.

I've always been a double-quoter, in contrast to most Python devs I know/work with. After we standardized on black, I got some satisfaction seeing all of my coworkers bend to my will (/s).

How narrow those two choices are! The correct answer is obviously to use single-quotes for keys and key-like cases and double-quotes for values. Make formatters impossible to write! (last sentence very /s, but that style actually exists)

That actually seems to be the de-facto Python style. Even Guido said at some point that that's his convention.
Post reply on HN