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

Django: Reformatted code with Black

github.com

Post reply on HN
Print view View original

131–140 of 256 posts

Re: Django: Reformatted code with Black

#131

Post by acdha »

MisterTea wrote: post #119
acdha wrote: post #82

Earlier quoted context omitted.

Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. One of the big problems here is that people notoriously conflate “familiar” with “better” and you rarely run the counter-experiment showing that after a couple weeks everyone would be familiar with any of the serious proposals. The advantage of a tool l…

> Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. It feels like we're trying to justify the continued employment of uncooperative, contrarian egoists. Pick a style and use it or they can go find another job to waste time debating nonsense.

There's some truth to that but I think it's more than that. This comes up all of the time in the UI world: if you ask people their opinion on something in the abstract, they'll often provide a ton of ideas but if you give them something which they can use now they'll probably either say it's okay or come up with a much smaller list of things they actually care about. Things like style guides are especially tricky here because people have opinions but they don't get a bill for changes — having a formatter available can shift that dynamic to where you can basically say “Black does this for free every time you hit save. Are you willing to build a tool which maintains that level of effort?”

I've had that happen a few times and the number of people who will volunteer opinions has consistently been at least an order of magnitude larger than those who are willing to contribute something like linter or formatter configuration.

Re: Django: Reformatted code with Black

#132

Post by coryrc »

perryizgr8 wrote: post #93
rob74 wrote: post #76

Earlier quoted context omitted.

Nah, I can totally understand why they decided to stay away from this can of worms. First, what max line width do you choose? Second, where do you break a line if it's too long? I think gofmt gets the balance exactly right: makes source code easier to read by providing a unified formatting style, but doesn't get in your way more than necessary.

> what max line width do you choose? 80 > where do you break a line if it's too long Wherever a keyword or name ends, but does not exceed 80. Gofmt has made opinionated decisions about everything, why stop at line breaks?

When I'm writing Python at Google, and get yet another error because my Python or Markdown line exceeds 80 characters, and read the fights on the mailing lists about changing the limit, I think Go was created because it was easier to create a whole new language than get the line length increased for Python.

Re: Django: Reformatted code with Black

#133

Post by stavros »

crad wrote: post #113
BiteCode_dev wrote: post #99

Earlier quoted context omitted.

yapf is configurable, and that's why it never won.

What's wrong with configurable? Too much opportunity to bikeshed? I figured yapf was not "new" which is why black won. Starting about 5-6 years ago there was a push in the Python community to replace solved problems with new ones in what appears to me as chasing the JavaScript community. Instead of consolidating on existing tools that worked well but had some rough edges to smooth out, numerous projects came about to…

> Too much opportunity to bikeshed?

Yes, and also too hard to set up. It's extremely dumb, but I'm much more likely to use something I can't configure, because if I can configure it, I'm going to want to, and it'll take forever to make all those choices.

Re: Django: Reformatted code with Black

#134

Post by jamessb »

ibejoeb wrote: post #25

In general, what are the strategies for large public codebases like this to mitigate supply chain attacks or other source-level attacks? For clarity, I'm hoping to open us discussion about how we're dealing with massive changesets like this that are difficult to review due chiefly to the breadth of it.

As a reformatting tool should only change the formatting, you could check that the Abstract Syntax Tree is unchanged. The ast module in the standard library gives access to the AST [1].

[1]: https://docs.python.org/3/library/ast.html

Re: Django: Reformatted code with Black

#135

Post by rob74 »

declnz wrote: post #13

Aside: I love a good linter, but as a long-time Python fan I find it sad that Black has so little configuration (yes, I know, but still) and moreover that it often produces code that no human Python dev I know would write... Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)

Well, you'll be surprised to find out that gofmt has exactly zero configuration. Ok, they (wisely in my opinion) decided not to mess with breaking lines automatically, and the job was far easier to do with a new language than with an already-established one where most developers have their long-treasured preferences.

Re: Django: Reformatted code with Black

#136

Post by flightlevel180 »

wodenokoto wrote: post #34
tomp wrote: post #27

worst things about Black: - doesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code - spurious changes in commits - if you happen to indent a block, Black will cause lines to break - Black fails at its most basic premise - "avo…

> - Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines regardless of width Yeah, this one drives me nuts too.

If I'm understanding your problem correctly, it seems that you can avoid it by using the --skip-magic-trailing-comma option [0].

[0] https://black.readthedocs.io/en/stable/the_black_code_style/...

Re: Django: Reformatted code with Black

#137

Post by saila »

tomp wrote: post #27

worst things about Black: - doesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code - spurious changes in commits - if you happen to indent a block, Black will cause lines to break - Black fails at its most basic premise - "avo…

I have to bump up my font size a bit and find 120 characters too wide on a 27" monitor where I need to look at multiple things side by side. It's also harder to read even when viewing a single file.

IMO, < 80 is ideal where possible with an absolute maximum of 99. I think Black's choice of 88 (plus maybe a little more in special cases) is quite good.

Re: Django: Reformatted code with Black

#138

Post by throwaway894345 »

coryrc wrote: post #132
perryizgr8 wrote: post #93

Earlier quoted context omitted.

> what max line width do you choose? 80 > where do you break a line if it's too long Wherever a keyword or name ends, but does not exceed 80. Gofmt has made opinionated decisions about everything, why stop at line breaks?

When I'm writing Python at Google, and get yet another error because my Python or Markdown line exceeds 80 characters, and read the fights on the mailing lists about changing the limit, I think Go was created because it was easier to create a whole new language than get the line length increased for Python.

Why do you get errors rather than auto-formatting (in the editor or in CI) and moving on with your day? I would have thought Google would have this sorted already?

Re: Django: Reformatted code with Black

#139

Post by throwaway894345 »

yawaramin wrote: post #128
throwaway894345 wrote: post #59

Earlier quoted context omitted.

> oesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the vertical space used by the code This is fine with me--I think it makes sense to optimize for readability, and I can read a long vertical list of arguments a lot more readily than a long comma-delineated…

> the default width should be at least 120 characters, I mean we're in 2022 after all Even in 2022, some people don't have wide external monitors, sometimes like to view two files (or a diff) side-by-side, or need to use GitHub/BitBucket/etc. code viewer pages. Also, it's still difficult for humans to read long lines.

Agreed. It's really nice to be able to have two files side-by-side (or a file plus a shell) without having tiny font. I still do the overwhelming majority of my work on a laptop--maybe I'd feel differently with one or more 27" 4K monitors, but even then I don't think a code formatter should make these kinds of assumptions.

Re: Django: Reformatted code with Black

#140

Post by atoav »

bwhmather wrote: post #84

Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits. 0: https://github.com/bwhmather/ssort

Some illustrative before-after syntax-highlighted code segments would be a nice addition for the readme.
Post reply on HN