[declnz]

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)

[Kinrany]

People conflate opinionated formats with autoformatting for some reason.

An autoformatter removes 99% effort from formatting code, and that includes code actively being worked on. Autoformatters are incredibly useful.

A standardized format removes effort spent learning to read a new format. That's an hour per format at most.

I don't see any good reasons for an autoformatter to enforce a standard. A standard would work just as well if defined as a specific configuration.

[njharman]

In 30yrs of dev the truest statement in standards I can make is that they change, all the time. The 2nd truest is I and coworkers have wasted far to much energy on arguing and maintaing STDs.

Blacks value isn't autoformatter, it's preemptive discussion ender.

[throwaway9870]

> Blacks value isn't autoformatter, it's preemptive discussion ender.

Exactly. I have learned that having it formatted just like I want it is FAR FAR FAR less important than having the entire ecosystem share a single format.

[throwaway9870]

I am just about to embark on resolving differences in our code base due to two different clang format files being used by different teams that have now merged. Can't wait to have all those conversations and discussion over which options are correct.

One hour my ass.

[3pt14159]

Well, sorta. It's really, really mentally annoying switching between projects where standards are different. For example 80 char limit to 120 char limit takes me at least a month to fully get used to. I agree black is better than the alternative, I agree it has downsides, I'm happy some of the parameters are tunable, but I'm also glad most of them are not. I just want to write software with tools I'm used to.

[jessaustin]

Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...

[barbazoo]

Are 120 chars bad?

[jessaustin]

Maybe it's because I only have one eye and the resulting slightly reduced width of field, but wide lines drive me crazy. I need to see the whole line without scanning. This was one of python's original appeals to me...

https://pep8.org/#maximum-line-length

[barbazoo]

I can see how that would make it hard for you. I hope your team is accommodating.

[rbanffy]

God made the ASR-33 teletype with 80 columns for a reason.

[dnate]

200 chars FTW

[s5806533]

moi

[crad]

yeah, it's just too bad that black violates PEP-8.

[rob74]

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.

[crad]

I'll take yapf --style=pep8 formatting over black any day.

[albertzeyer]

I found this comment: https://news.ycombinator.com/item?id=17155048

Are the mentioned issues resolved by now? E.g. the quadratic algorithm?

[0xJRS]

Having gone through the effort of testing yapf and black a few years back I also prefer yapf.

[alecbz]

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

[mrtranscendence]

Sometimes it takes code like this:

foo = (

    spark

    .read

    .parquet(...)

    .filter(...)

    .withColumn(...)

)

and turns it into

foo = spark.read.parquet(

    ...

).filter(

    ...

).withColumn(

    ...

)

which feels harder to parse for me. I also never quite got on board with the trailing commas.

[jreese]

Actually, modern versions of black will retain the fluent style you prefer, though it will collapse up to the first method call on the first line within the parens, so you end up with something like:

    foo = (
        spark.read.parquet(...)
        .filter(...)
        .withColumn(...)
    )

[philote]

Personally I prefer my code to read more like a sentence

instead

of

being

split

up

into

too

many

lines.

[ihaveajob]

I guess the point of the parent applies when the parameter lists are long, thus breaking the sentence-like appearance of the chained calls.

[BeFlatXIII]

These examples remind me why Elixir's pipe operator is so beloved.

[declnz]

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 the last few years I find devs are happier to format and push to "sort that problem out", leaving the readability benefit of that thought process lost.

TL;DR writing readable code isn't just about getting the spaces and brackets right...

[alecbz]

I tend to prefer the trailing paren on the following line. I'm not sure if there's a principled reason it helps (or hurts), but stuff like:

    assert outputs.get("foo.bar.baz", "default") == pytest.approx(
        time_recorder.time_taken, abs=0.0001)

always feels a bit off and "unbalanced" to me. The opening paren doesn't have anything immediately following it, so it feels 'symmetric' that the closing paren shouldn't have anything preceding it.

And also it feels like the open and closing parens should be on lines that start at the same indentation level. Honestly this I think does aid in readability a bit.

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

This feels orthogonal? The line is wrapping either way, which might sufficiently annoy someone to extract things out a bit more. But IMO it feels like a bit of an anti-pattern to create abstractions on the basis of syntax as opposed to the structure of the program.

> writing readable code isn't just about getting the spaces and brackets right...

? I mean of course not, but that's what we're talking about in the context of formatters right? I think the real, major way auto-formatters help with readability is by getting people to stop wasting mental cycles on things like spaces and brackets so that they can focus on more important code organization concerns.

[ziml77]

I agree with it feeling unbalanced. I don't register that statement as being complete. Putting the parenthesis on its own line is the same as putting a closing curly brace on its own line in languages that use those.

    int foo() {
        return 1; }

(This example actually breaks up vertically in my mind. As if it's just the number 1 being bracketed)

Maybe it could be broken up differently though to avoid the lone paren.

    assert (outputs.get("foo.bar.baz", "default") == 
        pytest.approx(time_recorder.time_taken, abs=0.0001))

[philote]

I also prefer the close paren to be on it's own line. Besides how it looks, it feels easier to me to add to the code inside the parens (but this is likely because I use vim).

[saila]

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.