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

211–220 of 262 posts

Re: Black: An uncompromising Python code formatter

#211

Post by samatman »

Izkata wrote: post #176
B1FF_PSUVM wrote: post #132

Earlier quoted context omitted.

> Originally PEP 8 had 79 characters. Now that was a weird choice so most companies went with 80 instead Probably thinking of one of these: - backslash continuations - terminals/etc that counted newlines - off by one errors

Also possibly a terminal text editor - the cursor sits on the column where the next character would be input (such as vim's insert mode). So with 79 character lines, the cursor is sitting at 80 while waiting for the next input. If your screen is larger than that it's no big deal, but if your screen is 80 columns and the cursor was at column 81, it would wrap to the next line without actually being a newline.

Yes.

The old standard was actually 78, so that a diff would fit on the screen.

Re: Black: An uncompromising Python code formatter

#212

Post by rndgermandude »

weberc2 wrote: post #193
zestyping wrote: post #188

Earlier quoted context omitted.

I thought of another way to express this that might resonate better. What I like about the Black philosophy is that it wants to make code style _uninteresting_. People should think about other things, not formatting. That's a great goal. So it seems to me that the best style choice is the most _boring_ choice. The least creative, least novel way. It should try to avoid inventing new formatting algorithms. What's the…

I’m a Python programmer and I never had the perception that single quotes are more canonical in any capacity. I always felt that single quotes were for degenerates who didn’t realize that single quotes are most commonly used for chars by the broader programming community. ;)

I despise people using single quotes even more than people using tabs instead of space, emacs instead of vim or GNU-style indentation instead of... anything sane :D

Re: Black: An uncompromising Python code formatter

#213

Post by zephyrfalcon »

ben509 wrote: post #161
zephyrfalcon wrote: post #33

Earlier quoted context omitted.

Not really. I worked at one place where they enforced PEP8 (using flake8 etc) using a git commit hook. In other words, when you try to commit some code, it would run flake8 which would most likely balk at some of the changes you made (and not let you commit until those were fixed). A lot of the rules/warnings are extremely nitpicky, and they had all of them turned on (except for the line length); I don't know how man…

> I can understand the argument for having all code in the same format, but this kind of mechanism just seriously decreased my productivity, not in the least because it constantly pissed me off. Globally, though, code is read an order of magnitude more times than it's written. So it's a huge productivity improvement in the not particularly long run.

That doesn't really apply here... Like I said, Python code is already much more uniform than most other programming languages. Unless somebody's formatting style is particularly ridiculous, their code should be just as readable as anybody else's, even if they put a space where it supposedly doesn't belong, or use too many/too few blank lines, or use the "wrong" way to split and indent a long list of function parameters. There is no productivity gain for others here. Maybe for languages like Javascript or C, but not Python. Almost all of it is just nitpicking.

(Of course you can make code less readable in other ways, e.g. by choosing undescriptive names, or weird idioms, but flake8/Black naturally don't address those issues.)

Re: Black: An uncompromising Python code formatter

#214

Post by Too »

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…

Visual studio has done auto formatting of c# since at least 2005. Ive used many other tool chains that does it before go became popular. As others noted, the biggest difference with gofmt is probably the lack of configuration.

Re: Black: An uncompromising Python code formatter

#215

Post by geofft »

hawkice wrote: post #210
geofft wrote: post #201

Earlier quoted context omitted.

The README confused me, but I think it's saying that it inserts spaces if needed to make it clear that it's a lower-precedence operator . But unlike operators like +, it's not one that inherently requires spaces. I tried out black and it does the following (the file originally had no spaces): x = a + b x = m[a:b] x = m[a + 1 : b] x = m[a:-b] x = m[a : 1 - b] I would personally still write m[a + 1:b], I think, but bla…

Wouldn't being closer imply being used together by the operator? So: 6/2 * 3 = 9 but 6 / 2*3 = 1? In the slice context it seems very obvious the colon has to be slicing, because it can't stand alone to produce an indexable value. But spacing should use this rule, right? [I think this rule was the one used by fortress, the Guy Steele language?]

Yes, that's the rule black is implementing (assuming I'm reading your comment right and understanding its README right...). m[a + 1:b] is in danger of being read as "take the slice 1-to-b, add it to a, index m on that" - even though we know that isn't a well-typed set of operations, the spacing implies that's how it should be read, same as e.g. m[a + 1/b].

Spacings that don't conflict with precedence are m[a+1:b], m[a+1 : b], or m[a + 1 : b]. While the middle one makes precedence obvious, all three are acceptable. black picks the latter, and I think it picks that one because of another rule that it should prefer writing a + 1 instead of a+1.

Re: Black: An uncompromising Python code formatter

#216

Post by Too »

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…

Why would you have strings that are not supposed to be human readable? Machine to machine should ideally use bytearray (b""-strings) or integer enums for that purpose.

Then you also have the ambiguity of what is considered human readable, is an xml document human readable? Http headers? File paths? Urls? Is a programmer considered human?

Re: Black: An uncompromising Python code formatter

#217

Post by spc476 »

samatman wrote: post #125
woolvalley wrote: post #121

Earlier quoted context omitted.

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

I use single quotes when the string in question is used like an enumeration:

    set_color('black','white')
And double quotes for strings meant to be read by a human:

    print("Hello there.  How are you?")
And an example with both forms:

    syslog('warning',"unit %s spin rate %f too low",u,rate)
For me, it's an indication of how I expect the string to be used.

Re: Black: An uncompromising Python code formatter

#218

Post by vijucat »

weberc2 wrote: post #193
zestyping wrote: post #188

Earlier quoted context omitted.

I thought of another way to express this that might resonate better. What I like about the Black philosophy is that it wants to make code style _uninteresting_. People should think about other things, not formatting. That's a great goal. So it seems to me that the best style choice is the most _boring_ choice. The least creative, least novel way. It should try to avoid inventing new formatting algorithms. What's the…

I’m a Python programmer and I never had the perception that single quotes are more canonical in any capacity. I always felt that single quotes were for degenerates who didn’t realize that single quotes are most commonly used for chars by the broader programming community. ;)

I've seen single quotes for chars vs. double quotes for Strings in Java, but in sh, it's "Strong Quoting with Single Quotes" vs. "Weak Quoting with Double Quotes":

http://www.grymoire.com/Unix/Quote.html#uh-1

"When you need to quote several character at once, you could use several backslashes. This is ugly but works. It is easier to use pairs of quotation marks to indicate the start and end of the characters to be quoted. Inside the single quotes, you can include almost all meta-characters"

So some of us associate single quotes with proper const strings, with no variable expansion, command substitution or other interpreter hanky-panky.

Re: Black: An uncompromising Python code formatter

#219

Post by takeda »

zephyrfalcon wrote: post #33
jowiar wrote: post #14

Earlier quoted context omitted.

If you’re working alone, fine. But when working with other people, getting everyone to do the same thing, and have that automatically done for you / enforces is incredibly valuable. It’s such a massive win that any deviation from “my personal optimum formatting” is rounding error.

Not really. I worked at one place where they enforced PEP8 (using flake8 etc) using a git commit hook. In other words, when you try to commit some code, it would run flake8 which would most likely balk at some of the changes you made (and not let you commit until those were fixed). A lot of the rules/warnings are extremely nitpicky, and they had all of them turned on (except for the line length); I don't know how man…

> Last but not least, PEP 8 is meant as a style guide, not as a book of law that needs to be enforced at all costs. Some of the Python core developers seem to agree; I have seen comments from Guido and others who apparently think that such tools go against the spirit of the PEP.

Actually PEP 8 starts with: "A Foolish Consistency is the Hobgoblin of Little Minds"[1] A lot of people miss that part.

[1] https://www.python.org/dev/peps/pep-0008/#id15

Post reply on HN