Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black: An uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

121–130 of 262 posts

Re: Black: An uncompromising Python code formatter

#121

Post by woolvalley »

mixmastamyk wrote: post #109
ambivalence wrote: post #84

Earlier quoted context omitted.

Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no spaces before colons on if-statements, defs, and so on) in the slice context. The language itself doesn't have an established standard in terms of string quote usage. If it did, Black would follow it. What repr() does is a weak indicator and how the documentation is…

Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.

Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.

Re: Black: An uncompromising Python code formatter

#122

Post by klodolph »

rhencke wrote: post #66
limsup wrote: post #60

Earlier quoted context omitted.

80 columns is very standard.

It was a standard from a time when we had green-screen terminals only capable of displaying an 80x24 grid of characters. ( https://en.wikipedia.org/wiki/VT100 ) It's worth asking - does the standard make sense still, given how we edit today?

It's not just about whether your hardware is capable of displaying wider lines. If it were only about hardware capability, why wouldn't we be writing code that's 200 or 300 characters wide?

* Studies of readability generally show that it declines once lines of text are longer than 60-70 characters, not counting whitespace or punctuation. At that point, humans have difficulty finding the beginning of the next line, which slows them down. You can compensate for this by increasing line spacing but you lose a bunch of space that way. The vast majority of professionally typeset natural language material is limited to about this length, or even shorter.

* People read code in terminals. Most terminals default to 80 columns wide. Consider people that develop on multiple computers and multiple OSs, and have to reconfigure them all. Or if you use a new computer or loaner computer the defaults will be back to 80. So if you change to 120 columns, you have to do it over and over again. Same with text editors, but less so.

* Side-by-side diffs can get cumbersome if the text is more than 80 columns wide, and consider that font sizes vary, and some people like their monitors vertical for reading diffs so they can see more context. On my 24" 1920x1200 monitor, I can easily read a side-by-side 80 column diff, very nearly 100, but definitely not 120.

* As a heuristic, an abundance of wide lines often indicate problems with the code itself. Too much nesting or something like that. This depends on the language and indentation used, it's generally accepted that Java code will be something like 25% wider.

I'm not saying that 80 columns is the right choice, only that there are reasons to support that choice. Just like there are reasons to choose 100 or 120.

Re: Black: An uncompromising Python code formatter

#123

Post by QasimK »

kbd wrote: post #104
itwy wrote: post #99

Earlier quoted context omitted.

So what? How is that harmful?

I take it it's because the migration files are auto-generated anyway, so it's odd to auto-format previously auto-generated files. You also don't really want to have repository churn on those files since they're generated once (and then never edited again) along with the feature they're for.

It would be a one-time auto-format just like the one-time auto-format that black will do for the rest of the project. Any newly auto-generated files can be formatted before they are committed. So I don't see it actually adding to the harm.

Re: Black: An uncompromising Python code formatter

#125

Post by samatman »

woolvalley wrote: post #121
mixmastamyk wrote: post #109

Earlier quoted context omitted.

Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.

Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.

Lua, and there are others. I favor double quotes for this same reason even when single quotes are allowed.

I'd like «guillemets» but that's going to have to be self-serve...

Re: Black: An uncompromising Python code formatter

#126

Post by lambda »

ambivalence wrote: post #31
aagimene wrote: post #27

Earlier quoted context omitted.

> It's not configurable. Except for the line length: > if you're paid by the line of code you write, you can pass --line-length with a lower number.

Yeah, I wasn't willing to die on that hill, especially that I'm introducing a new default value that wasn't popular before.

I've got to say, I'm quite happy with the default line length in Black.

The reason I always fight with people who want to increase line length is that they generally want to increase it to 100. Which is just a bit too big to fit two columns comfortably side by side at a reasonable size on a laptop screen, or three columns side by side on a wide desktop screen, which is how I generally set up my editors.

I'm always frustrated with codebases that use a 100 character standard, since I'm always running into lines that wrap, but when I use type annotations, 80 characters causes too many function signatures to have to wrap.

Re: Black: An uncompromising Python code formatter

#127

Post by platinumrad »

ljm wrote: post #106

In case of credit where credit’s due, is gofmt where the concept of auto-formatting syntax became mainstream? At first I hated it because I thought I had a style, but later on I enjoyed the consistency far more than I enjoyed my signature approach. A programming language has an opinion on how you build software with it, so it’s appreciated that it also has an opinion on how you should write it so that it remains cons…

I think the unconfigurability of gofmt may be its greatest strength. Indent, etc. have existed for years but getting everyone to just agree on a reasonable style is invaluable. GNU Indent's default style is one that (almost) nobody uses and the number of available options is overwhelming. rustfmt's default style is fine, but it also has an overwhelming number of options, in addition to not handling line wrapping well. ocp-indent is the only other formatter I've used that's as painless as gofmt.

Re: Black: An uncompromising Python code formatter

#128

Post by fishywang »

On the example there's:

    # in:

    TracebackException.from_exception(exc, limit, lookup_lines, capture_locals)
    
    # out:

    TracebackException.from_exception(
        exc, limit, lookup_lines, capture_locals
    )
I don't like this one. I would prefer that if you have )/]/} on the next line, then you should have a trailing comma, e.g.:

    TracebackException.from_exception(
        exc, limit, lookup_lines, capture_locals,
    )
Also I would prefer one-per-line over all in the same line (but not on the same line with the parentheses), but I feel less strongly about that one.

Re: Black: An uncompromising Python code formatter

#129

Post by lambda »

ambivalence wrote: post #95
danpalmer wrote: post #91

I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need to be human readable, single quotes otherwise. This makes it so obvious when something is going to be sent to the user, we find it really useful. That said, I think Black’s appeal is it’s uncompromising nature, so I wouldn’t ask it to change. Adding the option t…

Do you find your team enforcing the string quote rule consistently? It seems to me like it's easy to miss at times as automatic enforcement is impossible. Are there no cases where a string that wasn't originally planned to be user-visible ends up being so? I've heard this idea at times but when I looked at actual codebases it turns out it's more of an aspiration than an actual rule. And if you can't depend on it, why…

I kind of subconsciously do the same thing; use single quotes for symbol-like strings, and double for human readable.

But I can buy the argument that just having a single auto-enforced rule improves consistency and that has greater benefits than the somewhat vague distinction that is not enforced.

Re: Black: An uncompromising Python code formatter

#130

Post by Inityx »

woolvalley wrote: post #121
mixmastamyk wrote: post #109

Earlier quoted context omitted.

Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.

Eh, many programming languages use double quotes for strings, and single quotes for singular characters. Languages that can use single quotes for strings that I know of are ruby and python.

And even then, Perl and Ruby (heck, even Bash) have a semantic difference between double- and single-quoted strings. The only other popular general-purpose languages where they're synonymous are PHP, JavaScript, and Lua.
Post reply on HN