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

231–240 of 251 posts

Re: Black – Uncompromising Python code formatter

#231

Post by _fbpt »

AlexCoventry wrote: post #159
epistasis wrote: post #78

Earlier quoted context omitted.

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.

Try poetry. https://johnfraney.ca/posts/2019/03/06/pipenv-poetry-benchma...

I use poetry. It has bugs (`poetry install/add/update` treats git-URL dev-dependencies as end-user dependencies). I sent a bug fix and it was not merged for months. I now use my own fork of Poetry with this fix added.

Re: Black – Uncompromising Python code formatter

#232

Post by akvadrako »

hrktb wrote: post #132
CrLf wrote: post #39

Earlier quoted context omitted.

No, because I believe this is fundamentally unfixable. It's not a matter of changing this or that behavior, it's a matter of (apparent) formatting inconsistencies being important to convey intention and distinguish more important from less important bits. In the example I mentioned, I may sometimes choose to put a small dictionary initialization into a single line if it's just a detail, or may split it into multiple…

I don’t code in python so have no opinion on Black, but most code formatter can be adjusted to exclude some cases of formatting. I you would be fine with 95% of what it does and just want it to ignore the 5% where you care the most, I think the tool could benefit you. At least that’s how I feel about autoformatting in general.

Black is specifically designed to avoid being customizable, so you can't just exclude some cases.

Re: Black – Uncompromising Python code formatter

#233

Post by Ace17 »

askvictor wrote: post #214
hardwaregeek wrote: post #7

This is a case where I'm completely decided. Everybody should use an autoformatter. The minimal benefit you get from custom formatting is completely outweighed by the uniformity, the consistency and readability of autoformatted code.

How do you recommend fitting an autoformatter into a programming workflow? I'm using pycharm

All my projects have a top-level 'check' script, which always does, in order:

- reformat the whole codebase

- build (if needed, e.g a C++ project)

- run all tests

The programming workflow is then:

- edit code

- run the 'check' script

- repeat.

Re: Black – Uncompromising Python code formatter

#234

Post by jaimebuelta »

There are some things in Black that I don't particularly like, for example the preference for double quotes over single quotes...

But the part that drives me crazy is this...

    # in:

    ImportantClass.important_method(exc, limit, lookup_lines, capture_locals, extra_argument)

    # out:

    ImportantClass.important_method(
        exc, limit, lookup_lines, capture_locals, extra_argument
    )
instead of

    ImportantClass.important_method(exc, limit, lookup_lines, 
                                    capture_locals, extra_argument)
which to my eyes is way more readable and understandable. I understand what in some corner cases (if the call is too long that all arguments require its own line) it may be weird, but in those cases, it is showing that you try to do something strange in the first place (too long of a method name or too many elements in the call)

Re: Black – Uncompromising Python code formatter

#235

Post by georgyo »

jsmeaton wrote: post #223
yellowapple wrote: post #200

Played around with it in the sandbox and immediately disliked its insistence on putting every item in a sufficiently-long array on its own line. For example, something like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ] Black formats it to something more like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22…

Because it’s optimised for producing the smallest diff once it’s already been formatted and a change is made. If you add a single item to your preferred style, the entire thing has to be reflowed.

The line length thing is what I hate the most about black. It's way too religious.

For strings, it will format it like he formatted the array, and adding a word will reflow the entire block of text.

Re: Black – Uncompromising Python code formatter

#236

Post by anoncake »

jsmeaton wrote: post #223
yellowapple wrote: post #200

Played around with it in the sandbox and immediately disliked its insistence on putting every item in a sufficiently-long array on its own line. For example, something like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 ] Black formats it to something more like: foo = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22…

Because it’s optimised for producing the smallest diff once it’s already been formatted and a change is made. If you add a single item to your preferred style, the entire thing has to be reflowed.

Sometimes, optimizing for the smallest diff is clearly not worth it. For example:

    months = ["January", "February", "March", ...]
A human can make a smart decision, an autoformatter can't.

Re: Black – Uncompromising Python code formatter

#237

Post by anoncake »

misterdoubt wrote: post #226
anoncake wrote: post #186

Earlier quoted context omitted.

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

Making the code more clear to read helps its quality come through. Or its lack thereof.

Nothing stops a reviewer from reformatting the code before reading it (probably using an autoformatter).

But I'm not sure if making the code easier -- and thus faster -- to read is necessarily a good thing. If the brain parses and analyzes the code in parallel, making it harder to parse could give the analyzing process more time and thus make the review more thorough.

Of course, nothing stops a reviewer from being thorough either way. But making it the path of least resistance makes it more likely.

Re: Black – Uncompromising Python code formatter

#238

Post by anoncake »

JoBrad wrote: post #192
anoncake wrote: post #167

Earlier quoted context omitted.

Yeah, but no one would remove punctuation from a program because they think it looks nicer. > Javascript developers Oh, of course.

I remove semicolons from JS b/c I feel like they are a bit of a hack. Except where it's required by the language (for loops, which are becoming less used quite rapidly), your code generally shouldn't be so complex as to require semicolons for readability. Having said that, I've been introducing a lot more colons, since I use TypeScript.

I was referring to punctuation that is, in some way, actually necessary. No one ends their lines with semicolons in python although it's valid. The rules when the interpreter will "insert" them are obvious. Not so in Javascript.

Re: Black – Uncompromising Python code formatter

#239

Post by prirun »

fjp wrote: post #138
asdkhadsj wrote: post #85

Earlier quoted context omitted.

I'm not a python person (for many years, at least) , but I'd choose black for a completely different reason. By using Black, I'm choosing standardization over my whims. Which, as a longtime Go dev and now Rust dev, I love formatters that are opinionated. I don't always love what Gofmt or Rustfmt do, but I definitely like consistency that the community has in code style. So I don't care what Black thinks - I care what…

Our test pipeline fails any Python service trying to deploy if the black style check fails. I was initially grumpy about my org adopting black because I preferred single quotes, but the level of standardization is a huge win in my book. I never even think about my code style anymore, I just write it and then run black.

I started out double quoting but it takes longer to type Shift " vs ' so I switched early on.

Re: Black – Uncompromising Python code formatter

#240

Post by quietbritishjim »

konschubert wrote: post #149
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']…

Black does add brackets in some situations.

Frankly, that is a really annoying comment to make. Can it add brackets in the particular situation I just said? If so, I'd actually be interested, because it's while since I last checked so it could will have changed. But if not, you've made it look like my comment's invalid for no reason.

It reminds me of the last time Black came up on a Hacker News. I posted the same objection (but hypothetically) and the actual creator of Black replied with a comment along the lines of "you should check for yourself before making a comment like that". By the time I finally did check, the discussion had died down (like this one now has) and not many people saw the reply. As the creator, he must have known that my objection was correct but he posted a low-effort misleading comment that invalidated it. It doesn't give me a great feeling about the project. I realise you couldn't have known that happened but you can see why I find your reply so annoying.

Post reply on HN