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

221–230 of 256 posts

Re: Django: Reformatted code with Black

#221

Post by Bedon292 »

ibejoeb wrote: post #60
sciurus wrote: post #37

Earlier quoted context omitted.

For a purely mechanical change like this, someone could run black against the same revision of Django and verify the changes they see locally match the changes in this PR.

That's true as long as the results are predictable and reproducible. I don't happen to know if Black is, and it's not apparent from the documentation. Update: Found it: > How stable is Black’s style? > Starting in 2022, the formatting output will be stable for the releases made in the same year https://black.readthedocs.io/en/stable/faq.html

The same version of black, with the same settings, will always produce the same results from the same input code. Definitely re-producible. That question is about how stable the formatting is from version to version. Which is now more stable, and why Django finally made the move.

Re: Django: Reformatted code with Black

#222

Post by spc476 »

belval wrote: post #53
declnz wrote: post #28

Earlier quoted context omitted.

+1 ...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder

I disagree on that though. By sticking to vanilla Black (no pun intended) you ensure that people joining your time will probably already be familiar with the style, you prevent strongly opinionated employees from pushing for changes in the linter config. Black is opinionated, so it skips the debate entirely. We just use Black, not black with 120 characters lines, just Black. To each their own I guess, but to me it ju…

Yes, it's opinionated, but who's opinion got carved into stone?

Re: Django: Reformatted code with Black

#223

Post by spc476 »

glacials wrote: post #16

Black is slowly creeping into gofmt-level universality in the Python community and it’s great. The next big milestone is a first-party recommendation by python.org itself.

No, the next big milestone is embedding the format style as the syntax of the language. I'm curious as to why Go didn't even do this (they should have, in my opinion, but wimped out and left it to an external tool).

Re: Django: Reformatted code with Black

#224

Post by spc476 »

zmmmmm wrote: post #193
captainmuon wrote: post #48

Earlier quoted context omitted.

Naive question, but why is everybody so aggravated by formatting discussions? It seems to be a widespread opinion that these discussions are just 1) pointless and 2) difficult and time consuming. My personal experience is that 1) in many cases you do benefit from taking a moment, going through your code and thinking about presentation. And 2) I find it not at all difficult to settle. A change either doesn't matter, t…

Like you, I'm quite fascinated by the apparent massive frustration and time sink that is apparently happening due to formatting discussions. Been working nearly 25 years in software at all levels, rarely using auto-formatted code, literally can't remember having one of these discussions. If anything I might even say I wish people cared a little more. I do quite often artisanally craft formatting of specific code sect…

The industry doesn't want artisans, it wants cogs.

Re: Django: Reformatted code with Black

#226

Post by spc476 »

vitorfs wrote: post #24
supreme_berry wrote: post #12

“Black” developer refused for a long time to add option to format code with single quotes with very aggressive manners. Now Django devs didn’t see that option for single quotes and code looks unpleasant.

I have always used single quotes for Python code since I start working with it. When I started to adopt Black on my projects it indeed felt weird and the code looked unpleasant. But after a while you get used to it. Some people make the case that it's easier to write single quotes (well, depending on the keyboard format anyway). For keyboards in the US standard you have to hold the Shift key to write a double quote.…

I use single quotes for items that, while technically a string, could be considered a value or symbol. For example:

     syslog('debug',"Just opened %s for output",filename)
While there's no semantic difference between single and double quote, in my code base, there is. And if black becomes very popular, why even support single quotes anymore?

Re: Django: Reformatted code with Black

#228

Post by rufugee »

bwhmather wrote: post #150
evilsnoopi3 wrote: post #148

Earlier quoted context omitted.

We use isort[0] for this. It even has a "black" compatible profile that line spits along black's defaults. Additionally we use autoflake[1] to remove unused import statements in place. [0]( https://github.com/PyCQA/isort ) [1]( https://github.com/PyCQA/autoflake )

isort only sorts imports. ssort will sort all other statements within a module so that they go after any other statements they depend on. The two are complementary and I usually run both.

Thanks for your work on this. Coming back to python from golang, I really missed the auto-formatting. black plus something like ssort seems to bring the same to python. I've had really good results with black so far and look forward to trying ssort.

Re: Django: Reformatted code with Black

#229

Post by perryizgr8 »

radlad wrote: post #149
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?

IME 80 is terribly short in almost any language.

I like 80 because I can have three vertical windows open on my monitor and see everything without side scrolling.

Re: Django: Reformatted code with Black

#230

Post by wraptile »

TheRealPomax wrote: post #204

The reason to use Black is the same as Prettier on the HTML/CSS/JS side: forever stop having an opinion on code style, it's wasted time and effort. Any "it's not exactly what we want" comment with an attempt to customize the style to be closer to "what we were already using" is exactly why these things exist: by all means have that opinion, but that's exactly the kind of opinion you shouldn't ever even need to have,…

Except Python is a general purpose programming language so it's hard to have 1 shoe fits all solution when style vary based on medium you're working with. Are you making an OOP GUI app? Django? Something that is using loads of long Xpaths?
Post reply on HN