Black – Uncompromising Python code formatter • Hacker News Board

Re: Black – Uncompromising Python code formatter

#181

Post by kissgyorgy » Fri, May 17, 2019, 9:51 PM UTC

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.

Probably because pipenv is the worst Python package manager ever.

Re: Black – Uncompromising Python code formatter

#182

Post by cuddlecake » Fri, May 17, 2019, 9:58 PM UTC

rav wrote: post #16

hprotagonist wrote: post #6

The way you can tell that black is good is that everyone mildly dislikes a few things about it, but they're usually different things. That's usually a good clue that you've hit real middle-ground. I blackify my projects once we hit 3 contributors.

Why wait? I run black on all my new single-author projects.

I would do the same on any JS project with prettier.

I write some garbage-formatted code, press ctrl-s, and the code is formatted automatically.

Even on a single-dev project, I would take a config and just put it there for the convenience it provides me.

If I ever were to code python again, I would probably also use black.

Re: Black – Uncompromising Python code formatter

#183

Post by jhayward » Fri, May 17, 2019, 10:02 PM UTC

quietbritishjim wrote: post #147

Auto formatters are great but the problem with Black is that Python is fundamentally incompatible with them, at least if you're only willing to insert whitespace. For example a line of code like this: x = y[1]['a'] + z[2]['b'] can be broken like this in Black (if it's over the line length limit): x = y[1][ 'a'] + z[2]['b'] But it needs brackets inserted so that it can be formatted something like this: x = ( y[1]['a']…

My quick review of some changes Black made in the mercurial code base pointed out this same kind of thing in comprehensions, and a similar problem in the expressions of if statement.

I think the newline-after-bracket behavior looks like some brain damage based on how it likes lists formatted. The complaint I have on if clauses is that it doesn't break at logical operators, but rather at an open-paren, which just ruins the readability of compound expressions.

Re: Black – Uncompromising Python code formatter

#184

Post by cuddlecake » Fri, May 17, 2019, 10:07 PM UTC

frosted-flakes wrote: post #156

goostavos wrote: post #87

Earlier quoted context omitted.

That's pretty lazy thinking, imho. "Person x doesn't care about their code because they didn't use the formatting I like" Worrying about or judging code based on PEP8 is missing the forest for the trees[0] [0] https://www.youtube.com/watch?v=wf-BqAjZb8M

It's not that, it's that they use inconsistent and non-standard formatting. For example, in JavaScript, there is always a space before a function's opening curly bracket. This is pretty much a global standard, and it's rare to see code that doesn't follow this rule. However, I'll occasionally see code on Stack Overflow that randomly excludes these spaces. It honestly makes it so much harder to read, and I'm less will…

Technically, one could spend his life learning and perfecting JS or Python skills, without ever learning how other people format code. If you don't have a reference, you cannot align.

Also, imagine blind people coding. I imagine they have a completely different stance on how code should be formatted.

Re: Black – Uncompromising Python code formatter

#185

Post by GeorgeTirebiter » Fri, May 17, 2019, 10:29 PM UTC

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…

> there's a wealth of prior art to look at

Precisely. I wonder why ML has not been applied here.

Re: Black – Uncompromising Python code formatter

#186

Post by anoncake » Fri, May 17, 2019, 10:29 PM UTC

brootstrap wrote: post #68

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.

I don't think making code written by hacks look like code written by a competent programmer is a good thing.

Re: Black – Uncompromising Python code formatter

#187

Post by task_queue » Fri, May 17, 2019, 10:30 PM UTC

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.

> It's so slow so often, and I can't understand why.

The Python community is victim to pipenv's creator's marketing and shoehorning, that's why.

Re: Black – Uncompromising Python code formatter

#188

Post by jdmichal » Fri, May 17, 2019, 10:41 PM UTC

bunderbunder wrote: post #80

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…

That one actually makes a lot of sense to me, even if I've got to admit that I tend to go with the first option in my own code. It looks to me like a result of a couple rules that, in general, are sound: First, if an argument list can't fit all on one line, then every argument needs to go on a new line. And all the arguments need to be indented to the same level. The argument to that function includes the braces, so…

OTOH, something like this looks fine also, and is internally consistent with GP's single-block example:

    zipped = zip({
        apple.stem
        for satchel in satchels
        for apple in satchel
    }, {
        apple.core
        for satchel in satchels
        for apple in satchel
    })

Re: Black – Uncompromising Python code formatter

#189

Post by abtinf » Fri, May 17, 2019, 10:47 PM UTC

fwip wrote: post #88

abtinf wrote: post #82

Earlier quoted context omitted.

I think a nontrivial portion of Go’s success can be attributed to having a standard format and treating deviation as compiler errors. It is immensely valuable to be able to look at any Go code, whether in the toolchain, the standard library, or a random stackoverflow snippet, and not have to think about formatting at all.

I think you're conflating two concepts a little bit - deviation from `gofmt` isn't a compiler error, but lots of things (like unused variables or imports) are. I think they're both great.

You are corrrect. I guess I’ve learned to treat deviation from gofmt as error because of the go vim plugin. It runs goimports on save, which fixes a bunch of real errors (like unused imports).

Re: Black – Uncompromising Python code formatter

#190

Post by ForHackernews » Fri, May 17, 2019, 10:49 PM UTC

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 wish it had done this, rather than essentially codify the author's style.

Yeah, I keep seeing people singing the praises of black and I'm really dreading the inevitable future where people start acting like this dude's opinion is Correct Official Python Style.