6 ms·

Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those perso

Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those persons who adheres to the terminal 80 column rule, it's neat for splitting and cascades into many benefits. Python often looks like unkempt code to me, like the developer has no care for how it looks or layouts (which isn't true, it's Python's fault.) The forced indentation (I love proper formatting with consistency and indentation in languages) is among the first reasons I never liked or used Python, until recently when I gave in because it's such a great ecosystem to build scripts and such, but I still hate the formatting everyday. Clojure is beautiful though. Even C is gorgeous compared to a Python 'forced' program layout. I'll start adding Hy to the mix and touch vanilla Python as little as possible, but I still have to read library code.

growtofill 8y ago
Doesn't Python have an autoformatting tool like gofmt or Prettier?
- dhuramas 8y ago
  Yapf- https://github.com/google/yapf https://github.com/google/yapf
- baq 8y ago
  there's autopep8 and a few other tools but none are considered idiomatic.
- eirki 8y ago
  Black (The uncompromising Python code formatter) is all the rage atm. https://github.com/ambv/black https://github.com/ambv/black
- sametmax 8y ago
  Yes. Most of the projects now use black https://github.com/ambv/black https://github.com/ambv/black
  - quietbritishjim 8y ago
    The problem that black had last time I saw it on hacker news is that it only inserts whitespace. Unlike braces-and-semicolon languages, that is sometimes not enough to format code well. For example, given the following line: x[1][4] = a[2] + b[4] Black will format like either of these: x[1][ 4] = a[2] + b[4] x[1][4] = a[ 2] + b[4] But not like either of these, unless you insert the brackets yourself: x[1][4] = ( a[2] + b[4]) x[1][4] = (a[2] + b[4]) Maybe this sounds like just one little problem but I think it's a fundamental flaw. I have seen the result of a Python formatter (not Black but had the same problem) applied to a couple of files and it's a total mess. I'd take inconsistent column widths over that any day. I asked the creator of black about it and he was pretty dismissive.
    - Rotareti 8y ago
      I use yapf and in such cases backslashes work fine: x[1][4] =\ a[2] + b[4]
vaylian 8y ago
I follow the 80 columns rule as well. Do you have an example of such unkempt code that you can share?
freyir 8y ago
> Python formatting is egregious though, with hopelessly long lines This is the result of writing hopelessly long lines of code. Python doesn't force you to write long lines. I've done it myself, many times, but gradually made efforts to avoid this. I'll move deeply indented code into a new function or split up a long expression with a temporary variable. If I run into a particularly hard-to-format portion of code, it's usually a sign of that my code could be better.
- goldfeld 8y ago
  But list/dict comprehension puts the programmer in bad shoes, because anything interesting/powerful done with it gets dangerously long. This and other features where non-trivial statements or calls are written seem poorly thought-out, from a formatting perspective (nevermind 120 columns being the style goal for the language and common IDEs, already longish for term vim and Emacs.) Adding to it for the other commenter (vaylian) who asked for example code, pretty much any codebase I've been delving into will have at least one ugly line per non-trivial class implemented (some undergo TWO virtual linebreaks!! Maybe OK for mouse-clickers but vimmers recoil and shriek.) It just doesn't play nice. I won't go into how I dislike the class system which feels bolted-on (to a script language) too because then that'd be a bit unfair and off-topic.
  - int_19h 8y ago
    Comprehensions are very easy to format spanned across multiple lines - since they're always enclosed in some kind of brackets, you can split them over multiple lines in a readable fashion: ys = [x + 1 for x in xs if x > 0] or: ys = [ x + 1 for x in xs if x > 0 ]
    - speedplane 8y ago
      Both of the examples you give are far less readable than an equivalent for loop with an if statement. Programmers use comprehensions because there is an understanding that they are more efficient and the compiler/interpreter can better optimize them.
int_19h 8y ago
Long lines come most often in conditions of if- and while-blocks, mostly because there's no way to split them over multiple lines that isn't visually hideous. But a condition can be easily split if it is assigned to a variable, and that variable then tested. And naming said variable well can make a comment explaining the condition redundant.
- goldfeld 8y ago
  Yes, that's a great example, especially with deep nesting which forced indentation makes worse. But the solution feels like working against the grain, when a language should be working for human readability, not for workarounds to make a scripting language featureful.
  - int_19h 8y ago
    One would argue that forcing long conditions to be split up, and intermediate steps named, is rather encouraging readability. ~
- jononor 8y ago
  Yes, prefer a named variable if the logic gets long. If it is really long, consider introducing a function to calculate the predicate.
deleted 8y ago
[deleted]

growtofill 8y ago

Doesn't Python have an autoformatting tool like gofmt or Prettier?

dhuramas 8y ago
Yapf- https://github.com/google/yapf https://github.com/google/yapf
baq 8y ago
there's autopep8 and a few other tools but none are considered idiomatic.
eirki 8y ago
Black (The uncompromising Python code formatter) is all the rage atm. https://github.com/ambv/black https://github.com/ambv/black
sametmax 8y ago
Yes. Most of the projects now use black https://github.com/ambv/black https://github.com/ambv/black
- quietbritishjim 8y ago
  The problem that black had last time I saw it on hacker news is that it only inserts whitespace. Unlike braces-and-semicolon languages, that is sometimes not enough to format code well. For example, given the following line: x[1][4] = a[2] + b[4] Black will format like either of these: x[1][ 4] = a[2] + b[4] x[1][4] = a[ 2] + b[4] But not like either of these, unless you insert the brackets yourself: x[1][4] = ( a[2] + b[4]) x[1][4] = (a[2] + b[4]) Maybe this sounds like just one little problem but I think it's a fundamental flaw. I have seen the result of a Python formatter (not Black but had the same problem) applied to a couple of files and it's a total mess. I'd take inconsistent column widths over that any day. I asked the creator of black about it and he was pretty dismissive.
  - Rotareti 8y ago
    I use yapf and in such cases backslashes work fine: x[1][4] =\ a[2] + b[4]

vaylian 8y ago

I follow the 80 columns rule as well. Do you have an example of such unkempt code that you can share?

freyir 8y ago

> Python formatting is egregious though, with hopelessly long lines This is the result of writing hopelessly long lines of code. Python doesn't force you to write long lines. I've done it myself, many times, but gradually made efforts to avoid this. I'll move deeply indented code into a new function or split up a long expression with a temporary variable. If I run into a particularly hard-to-format portion of code, it's usually a sign of that my code could be better.

goldfeld 8y ago
But list/dict comprehension puts the programmer in bad shoes, because anything interesting/powerful done with it gets dangerously long. This and other features where non-trivial statements or calls are written seem poorly thought-out, from a formatting perspective (nevermind 120 columns being the style goal for the language and common IDEs, already longish for term vim and Emacs.) Adding to it for the other commenter (vaylian) who asked for example code, pretty much any codebase I've been delving into will have at least one ugly line per non-trivial class implemented (some undergo TWO virtual linebreaks!! Maybe OK for mouse-clickers but vimmers recoil and shriek.) It just doesn't play nice. I won't go into how I dislike the class system which feels bolted-on (to a script language) too because then that'd be a bit unfair and off-topic.
- int_19h 8y ago
  Comprehensions are very easy to format spanned across multiple lines - since they're always enclosed in some kind of brackets, you can split them over multiple lines in a readable fashion: ys = [x + 1 for x in xs if x > 0] or: ys = [ x + 1 for x in xs if x > 0 ]
  - speedplane 8y ago
    Both of the examples you give are far less readable than an equivalent for loop with an if statement. Programmers use comprehensions because there is an understanding that they are more efficient and the compiler/interpreter can better optimize them.

int_19h 8y ago

Long lines come most often in conditions of if- and while-blocks, mostly because there's no way to split them over multiple lines that isn't visually hideous. But a condition can be easily split if it is assigned to a variable, and that variable then tested. And naming said variable well can make a comment explaining the condition redundant.

goldfeld 8y ago
Yes, that's a great example, especially with deep nesting which forced indentation makes worse. But the solution feels like working against the grain, when a language should be working for human readability, not for workarounds to make a scripting language featureful.
- int_19h 8y ago
  One would argue that forcing long conditions to be split up, and intermediate steps named, is rather encouraging readability. ~
jononor 8y ago
Yes, prefer a named variable if the logic gets long. If it is really long, consider introducing a function to calculate the predicate.

deleted 8y ago

[deleted]