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

101–110 of 251 posts

Re: Black – Uncompromising Python code formatter

#101

Post by camgunz »

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.

I'm not looking for an "excellent" standard. I'm looking for something that isn't a complete outlier.

I feel like in every one of these formatter discussions people are waiting to pounce on anyone who takes issue with the formatting. I'm totally down with formatting: prettier, dart_style, rustfmt, gofmt, uncrustify, I use and love them all both professionally and personally (well, gofmt is bad at wrapping but the language is bad at wrapping in general). But in all these cases, these tools are either configurable or they set a standard for how to format code for $lang. Black does neither, which is fine, but its options then are "pick a common convention" or "pick an uncommon convention". All I'm saying is that I wish it had done the former.

Re: Black – Uncompromising Python code formatter

#102

Post by andbberger »

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…

Counterpoint: I do this all the time, and I write a lot of Python

Re: Black – Uncompromising Python code formatter

#103

Post by a1369209993 »

photonios wrote: post #26
CrLf wrote: post #17

I've been using it for a few months now, but I don't really like it. It does remove quabbles about formatting, but I've personally never felt that as a problem and it just replaces them with constant frustration. I think code formatting is very important for readability, and I think many (subtle) choices about how to make a piece of code more readable are very subjective. These types of tools are just incapable to ma…

You could configure your IDE to re-format files into your favorite format and just have a pre-commit hook that formats them back into the official format. That's how I work. No arguments about style and formatting, yet I get to make the code look how I personally prefer it.

No, we can't. My (and, by the sound of it, CrLf's) favorite format relies on information that your pre-commit hook has artificially removed from the code. Eg:

  munge(gidget,
    thing1,thing2,thing3);
  cmplt(dtypeA,valueA,
        dtypeB,valueB);
(Most cases are more subtle (and thus less amenable to "oh, you just need to build a complete static type checker into the formatter") than this, but I wanted an obvious example.)

Re: Black – Uncompromising Python code formatter

#104

Post by camgunz »

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…

Let me introduce you to Uncrustify (well, its GUI anyway) [1]. It's ridiculously configurable and super good at what it does.

[1]: http://universalindent.sourceforge.net/screenshots.php

Re: Black – Uncompromising Python code formatter

#105

Post by ben509 »

epistasis wrote: post #78
ben509 wrote: post #72

Earlier quoted context omitted.

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

I'm coming from managing virtualenvs with s*ty bash scripts on a complex application, so pipenv got rid of a ton of jank, even though it's slow and has issues resolving certain dependencies.

I like it because I can document most maintenance tasks as "pipenv sync && pipenv run X" and they Just Work with exactly the library versions specified for that commit.

But definitely look into poetry if you're packaging a library.

Re: Black – Uncompromising Python code formatter

#108

Post by ben509 »

awinder wrote: post #71
adossi wrote: 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

Because you don't know if they've done the trick. That's why natural language is padded with extra words to add context and help rule out misunderstandings. The grammatical rules of agreement are one mechanism to do this.

And you can see the phenomenon of over-abbreviation by reading a few debates on twitter and repeatedly seeing, "how can you not understand what I tweeted?!"

Re: Black – Uncompromising Python code formatter

#109

Post by ali_m »

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 actually much prefer Black's version in this case. I find nested comprehensions quite a lot easier to read if they are broken onto multiple lines.

Re: Black – Uncompromising Python code formatter

#110

Post by c0un7d0wn »

mlevental wrote: post #33
fredley wrote: post #21

We use Black in a pre-commit hook for all our python code. It makes legibility and formatting a non-issue in the team. Yes it can look strange at first if you're not used to it, but after a while it makes formatting invisible (and it's odd reading non-black python). Would recommend.

how do you do this? do you have a jenkins server running that does the formatting? i would love to set this up because while i use black religiously i cannot for the life of me convince my boss get in the habit of using it (which is crazy because your commits are always fighting on whitespace).

See https://github.com/shosca/django-sorcery/blob/master/Makefil... for example

Run that target as part of the test

Post reply on HN