5 ms·

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 of

by declnz 5y ago

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)

alecbz 5y ago
OOC what are your grips with black's style? I generally find black pretty "beautiful" (concise maybe not as much).
- declnz 5y ago
  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 5y ago
    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.
    - philote 5y ago
      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).
    - ziml77 5y ago
      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))
  - saila 5y ago
    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.
- mrtranscendence 5y ago
  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.
  - philote 5y ago
    Personally I prefer my code to read more like a sentence instead of being split up into too many lines.
    - ihaveajob 5y ago
      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 5y ago
        These examples remind me why Elixir's pipe operator is so beloved.
  - jreese 5y ago
    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(...) )
Kinrany 5y ago
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.
- crad 5y ago
  yeah, it's just too bad that black violates PEP-8.
- 3pt14159 5y ago
  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 5y ago
    Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...
    - barbazoo 5y ago
      Are 120 chars bad?
      - jessaustin 5y ago
        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 https://pep8.org/#maximum-line-length
crad 5y ago
I'll take yapf --style=pep8 formatting over black any day.
- 0xJRS 5y ago
  Having gone through the effort of testing yapf and black a few years back I also prefer yapf.
- albertzeyer 5y ago
  I found this comment: https://news.ycombinator.com/item?id=17155048 https://news.ycombinator.com/item?id=17155048 Are the mentioned issues resolved by now? E.g. the quadratic algorithm?
rob74 5y ago
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.

by declnz 5y ago

alecbz 5y ago

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

declnz 5y ago
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 5y ago
  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.
  - philote 5y ago
    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).
  - ziml77 5y ago
    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))
- saila 5y ago
  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.
mrtranscendence 5y ago
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.
- philote 5y ago
  Personally I prefer my code to read more like a sentence instead of being split up into too many lines.
  - ihaveajob 5y ago
    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 5y ago
      These examples remind me why Elixir's pipe operator is so beloved.
- jreese 5y ago
  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(...) )

Kinrany 5y ago

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.

crad 5y ago
yeah, it's just too bad that black violates PEP-8.
3pt14159 5y ago
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 5y ago
  Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...
  - barbazoo 5y ago
    Are 120 chars bad?
    - jessaustin 5y ago
      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 https://pep8.org/#maximum-line-length

crad 5y ago

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

0xJRS 5y ago
Having gone through the effort of testing yapf and black a few years back I also prefer yapf.
albertzeyer 5y ago
I found this comment: https://news.ycombinator.com/item?id=17155048 https://news.ycombinator.com/item?id=17155048 Are the mentioned issues resolved by now? E.g. the quadratic algorithm?

rob74 5y ago

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.