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

241–250 of 262 posts

Re: Black: An uncompromising Python code formatter

#241

Post by rapind »

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.

The "visual noise" makes it clearer the me that it surrounds a block of text, so I don't buy this.

Double quotes are also the convention in english to delineate a literal, so I would argue it's more obvious.

I'll grant you keyboard presses though. There's an obvious advantage to single quotes here, but consider why this is the case. To make the use of "apostrophe" more efficient since it appears far more often than a double quote in english. I suppose it's pragmatic to leverage this advantage in code where string quoting is extremely common...

Perhaps double quoting is a bias I've developed writing code, but I suspect it's actually a bias I carried over from reading and writing english and what simply seemed more obvious.

Language design than supports both makes me crazy. Pick one and enforce it!

Re: Black: An uncompromising Python code formatter

#242

Post by ambivalence »

danpalmer wrote: post #221
ambivalence wrote: post #95

Earlier quoted context omitted.

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…

> Do you find your team enforcing the string quote rule consistently? Yes. It's pretty much the only formatting style point that we don't have automated. > As for number of lines after imports, how is a lack of enforcement there stopping you from using the tool? Our current automated linting enforces it, but Black doesn't always reformat it, so we might get linter errors from Black formatted code.

> Yes. It's pretty much the only formatting style point that we don't have automated.

Alright, fair enough!

> Black doesn't always reformat it, so we might get linter errors from Black formatted code.

Well, as long as it doesn't add new linter errors, that should be fine, do you disagree?

There are always going to be suboptimal formattings and missing transformations but as long as the situation gets better automatically on average and can be further improved with minimal manual input, you should be fine.

Re: Black: An uncompromising Python code formatter

#243

Post by ambivalence »

quietbritishjim wrote: post #223

The problem with code formatters for Python is that you can't just break lines using whitespace; you need to insert symbols, ideally parentheses. For example, if you need to break this line of code: left[first][second] = right[first][second][third] Manual breaking looks like this: left[first][second] = ( ‎right[first][second] [third] ) Code formatters will produce something like the following atrocity: left[first][se…

Did you actually try Black on a line like this?

Re: Black: An uncompromising Python code formatter

#244

Post by ambivalence »

jhall1468 wrote: post #235
prawl wrote: post #200

Earlier quoted context omitted.

This isn't a vast majority by any stretch of the imagination.

The overwhelming response here saying use single quotes begs to differ.

That's not how this works. All the people who are just happy or indifferent about double quotes don't comment about it. And some of the ones that aren't happy about it commented here multiple times.

Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

Re: Black: An uncompromising Python code formatter

#245

Post by limsup »

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?

I exclusively program on a small laptop and don't have great eyesight. Formatting code such that it only looks good on huge displays makes my life more difficult.

Re: Black: An uncompromising Python code formatter

#246

Post by pkilgore »

ambivalence wrote: post #244
jhall1468 wrote: post #235

Earlier quoted context omitted.

The overwhelming response here saying use single quotes begs to differ.

That's not how this works. All the people who are just happy or indifferent about double quotes don't comment about it. And some of the ones that aren't happy about it commented here multiple times. Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

Selection bias is real here.

I thought dbl quotes smart for all the reasons in the readme. Me commenting 'this is great' is just noise on HN, and discouraged by the rules. Never take self-selected anything as truth, especially comments (tweets/posts/voluntary votes)

Re: Black: An uncompromising Python code formatter

#247

Post by quietbritishjim »

ambivalence wrote: post #243
quietbritishjim wrote: post #223

The problem with code formatters for Python is that you can't just break lines using whitespace; you need to insert symbols, ideally parentheses. For example, if you need to break this line of code: left[first][second] = right[first][second][third] Manual breaking looks like this: left[first][second] = ( ‎right[first][second] [third] ) Code formatters will produce something like the following atrocity: left[first][se…

Did you actually try Black on a line like this?

I must admit I didn't. I felt confident it was restricted to adding and removing whitespace because the README says at the start:

> Black ignores previous formatting and applies uniform horizontal and vertical whitespace to your code.

I now see it does sometimes modify non-whitespace characters e.g. later in the README it mentions:

> In [certain] cases, parentheses are removed when the entire statement fits in one line

I'm not in a position to test black out right now (I can't run Python on the computer I'm posting this comment on). I'd be curious to know what it does on the code I posted, and on over-length comments and string literals.

Re: Black: An uncompromising Python code formatter

#248

Post by freyir »

ambivalence wrote: post #243
quietbritishjim wrote: post #223

The problem with code formatters for Python is that you can't just break lines using whitespace; you need to insert symbols, ideally parentheses. For example, if you need to break this line of code: left[first][second] = right[first][second][third] Manual breaking looks like this: left[first][second] = ( ‎right[first][second] [third] ) Code formatters will produce something like the following atrocity: left[first][se…

Did you actually try Black on a line like this?

In:

    left[a_rather_long_key][a_rather_long_key] = right[a_rather_long_key][a_rather_long_key][a_rather_long_key]
Out:

    left[a_rather_long_key][a_rather_long_key] = right[a_rather_long_key][
        a_rather_long_key
    ][a_rather_long_key]

Re: Black: An uncompromising Python code formatter

#249

Post by freyir »

quietbritishjim wrote: post #247
ambivalence wrote: post #243

Earlier quoted context omitted.

Did you actually try Black on a line like this?

I must admit I didn't. I felt confident it was restricted to adding and removing whitespace because the README says at the start: > Black ignores previous formatting and applies uniform horizontal and vertical whitespace to your code. I now see it does sometimes modify non-whitespace characters e.g. later in the README it mentions: > In [certain] cases, parentheses are removed when the entire statement fits in one li…

I tried it. Black doesn't seem to touch long strings or comments. It just leaves you with "line too long" errors that you can clean up yourself.

For your code example, see my comment above.

Re: Black: An uncompromising Python code formatter

#250

Post by gregw2 »

nemoniac wrote: post #224
ambivalence wrote: post #31

Earlier quoted context omitted.

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

Ah but there's the irony. Everyone would like to stick to the standard formatting rules. Well... except for that one little idiosyncratic thing that they just won't sacrifice. Then black comes storming in to enforce conformity. Well... except for that one little idiosyncratic thing the author of black just can't bring himself to adhere to. Don't get me wrong. I'm a big fan of the approach in general. I use things lik…

Time for a fork!

Let's call it "black-ish"

Post reply on HN