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

61–70 of 251 posts

Re: Black – Uncompromising Python code formatter

#61

Post by adossi »

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.

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

Re: Black – Uncompromising Python code formatter

#62

Post by mixmastamyk »

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…

Agreed. Would also like an alternative that used single-quotes instead. Do yapf or autopep8 have that option?

Re: Black – Uncompromising Python code formatter

#63

Post by rahimnathwani »

DEP 0008 ('Formatting Code with Black') was accepted by the Django board last week. They're going to wait until Black has a stable release before reformatting all the code, as there's at least one thing they don't like about how Black handles things.

https://github.com/django/deps/blob/master/accepted/0008-bla...

https://groups.google.com/forum/#!topic/django-developers/7G...

Re: Black – Uncompromising Python code formatter

#64

Post by infecto »

I have just started using it and love it. It sounds funny but while formatting is not always a deal breaker it still kills me for 1) readability and 2) the faith that when someone reads the code base later one they know I was not an idiot.

I know 2 is kind of subjective but when I look at someone elses code and I see obvious mistakes against pep8 I start judging both the person and the code harshly. Perhaps unfair but for the very simple pep8 rules I see it as someone who is not as well versed in Python and perhaps does not care about their code as much.

Overall I just concede that consistency is better than everyones personal tastes. For a startup I think you can get by with just some custom linting but in a larger org I find it much harder to agree on a consistent format unless you are a Python first org. Much easier just to roll Black into the project and go with it.

Re: Black – Uncompromising Python code formatter

#65

Post by strangemonad »

p0cc wrote: post #5

I use black because it is idempotent. Google's yapf lacks this property. Edit: Previous discussion: https://news.ycombinator.com/item?id=17155048

Unrelated: thank you for using “idempotent” correctly. Too many people use it to mean referential transparency or having a functionality property

Re: Black – Uncompromising Python code formatter

#66

Post by plorkyeran »

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

Re: Black – Uncompromising Python code formatter

#67

Post by bunderbunder »

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.

They're not very important if you're the only developer on your team.

If you're working with others, though, then it becomes very important. I don't think I'm being entirely hyperbolic when I say that inconsistent or poorly-chosen formatting rules are the death of 1,000 cuts for a team's productivity.

There's a tiny but existent cost that's incurred every time formatting rules that aren't diff-stable result in a noisy code review that takes longer to read, or makes it harder for reviewers to discern the real changes from the formatting junk. There's a tiny but existent cost when excess delta makes it harder to gitblame. There's a tiny but existent cost when people have to stop and think about how to format their code manually. Or when they have to stop and debate formatting. Or when they read someone else's code slightly more slowly because different formatting rules make it harder for them to skim it or rely on pattern recognition instead of careful reading to understand its structure.

All those tiny little costs add up to something that's not so tiny. And it's so easy to make it just disappear, for the low low cost of swallowing one's pride, by simply adopting an opinionated autoformatter.

Re: Black – Uncompromising Python code formatter

#68

Post by brootstrap »

ed_balls wrote: post #4

I use black every day. It's pretty good. The hours you save on pointless arguments e.g. ' or " is better as default for strings. I wish it'd come with standard python distribution `python fmt`

yeah, someone above mentioned that with Go as the example. It's pretty nifty in some cases but think there are two sides to the story. I know folks who write lovely python code everytime. I know others at my gig who even after 3 years are not putting spaces after equals sign (and other PEP/flake8 blunders) and every PR is littered with syntactic errors. The code formatter is brilliant for this case.

Re: Black – Uncompromising Python code formatter

#69

Post by darepublic »

mlevental wrote: post #34
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…

who cares what it looks like. it's meaningless (as long as it doesn't break things, which black doesn't). the only thing that matters is consistency.

the outputted code should at least be decently readable and predictable, otherwise I don't see the point of having a formatter at all.

Re: Black – Uncompromising Python code formatter

#70

Post by tda »

2Ccltvcm wrote: post #30

Black is essential for maintenance of Pandas code which uses method chaining. If you use Pandas you should be using method chaining and therefore also black.

However the pandas source is not blackened, and I really miss not be able to just fix all formatting issues while working on a PR. After just a few months I am so used to black it just feels weird to not have it everywhere
Post reply on HN