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

141–150 of 256 posts

Re: Django: Reformatted code with Black

#141

Post by saila »

declnz wrote: post #26
alecbz wrote: post #15

Earlier quoted context omitted.

OOC what are your grips with black's style? I generally find black pretty "beautiful" ( concise maybe not as much).

I guess the closing parens irk me the most e.g. assert outputs.get("foo.bar.baz", "default") == pytest.approx( time_recorder.time_taken, abs=0.0001 ) I get why it's done that, but I just don't think it helps humans read. Part of the twisted beauty of PEP-008's narrow lines is that you're forced to extract (named) variables, or avoid overly indented code by extracting methods or applying higher level abstractions. In…

This looks like bad coding style to me--trying to cram too much on a line and an overly complex conditional expression.

Using the same three lines, you could instead assign each result to a temporary var:

    x = outputs.get("foo.bar.baz", "default")
    y = pytest.approx(time_recorder.time_taken, abs=0.0001)
    assert x == y
If using an assert method, I think this looks okay too (although still a bit noisy):

    self.assertEqual(
        outputs.get("foo.bar.baz", "default"),
        pytest.approx(time_recorder.time_taken, abs=0.0001),
    )
I find that if black produces ugly output, it's usually because of something that I could improve, and I appreciate the hint.

Re: Django: Reformatted code with Black

#142

Post by digisign »

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…

My monitor is in portrait mode. Even when I used one in landscape, I typically had two windows side by side. So extra-wide lines of code are less readable.

Re: Django: Reformatted code with Black

#143

Post by aaronchall »

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

Does it put high-level business logic at the top or the implementation details at the top?

Which is preferable, and why?

Re: Django: Reformatted code with Black

#144

Post by digisign »

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

The repl still uses single quotes.

Re: Django: Reformatted code with Black

#145

Post by digisign »

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.

Use nero or blue instead, which both use single quotes.

Re: Django: Reformatted code with Black

#146

Post by eredengrin »

BiteCode_dev wrote: post #115
crad wrote: post #113

Earlier quoted context omitted.

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…

There is no "best format". It's a matter of opinion. Taste is something we cannot objectively agree, and in fact, people will end up arguing even about this very statement, offering what they think is an objective measure. Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration. To be redone for each project, team, etc. Worse even in FOSS where everybody will come in a tic…

> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration

Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and live with it forever, that's how those teams work.)

> Black took the road of gofmt: you can't chose. And it won because of that: it saved people time and energy.

I don't see how this follows, if a team was dysfunctional enough to be wasting hours and hours of time before, I can't imagine why that wouldn't continue. It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options".

Re: Django: Reformatted code with Black

#147

Post by coryrc »

throwaway894345 wrote: post #138
coryrc wrote: post #132

Earlier quoted context omitted.

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?

I know! Usually the editor autoformats on save and while typing, but there are some edge cases where the regular incremental formatter fails but it's rare enough that I don't reflexively hit the "format all files" button and then get caught out by pre-submit tests.

Re: Django: Reformatted code with Black

#148

Post by evilsnoopi3 »

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

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)

Re: Django: Reformatted code with Black

#149

Post by radlad »

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?

IME 80 is terribly short in almost any language.

Re: Django: Reformatted code with Black

#150

Post by bwhmather »

evilsnoopi3 wrote: post #148
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

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.
Post reply on HN