Black: An uncompromising Python code formatter • Hacker News Board

Re: Black: An uncompromising Python code formatter

#221

Post by danpalmer » Sat, May 26, 2018, 8:56 AM UTC

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…

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

Re: Black: An uncompromising Python code formatter

#222

Post by danpalmer » Sat, May 26, 2018, 8:56 AM UTC

waleedka wrote: post #113

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…

One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded stri…

Yep, as others have commented, this is what I meant by using the translation tools.

Re: Black: An uncompromising Python code formatter

#223

Post by quietbritishjim » Sat, May 26, 2018, 9:33 AM UTC

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][second
        ‎] = right[first][second][
        third]

Comments and strings are also unwrappable if the formatter is afraid of inserting characters.

Re: Black: An uncompromising Python code formatter

#224

Post by nemoniac » Sat, May 26, 2018, 9:35 AM UTC

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.

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 like paredit-mode and aggressive-indent-mode and whitespace-mode and I've just set up emacs to use black together with blacken-mode, but with blacken-line-length set to 80.

Re: Black: An uncompromising Python code formatter

#225

Post by Fizzadar » Sat, May 26, 2018, 9:53 AM UTC

This is great - especially _removing_ hanging indents which is a real pet hate of mine! Only issue is the quotes - I'd love to see Black leave those as single if flake8 is configured to do so, for all the reasons mentioned in the comments.

Re: Black: An uncompromising Python code formatter

#226

Post by heavenlyblue » Sat, May 26, 2018, 10:01 AM UTC

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 always thought that double quotes are for degenerates who don’t pay attention to what a standard repr output is for strings.

Re: Black: An uncompromising Python code formatter

#227

Post by jwilk » Sat, May 26, 2018, 10:02 AM UTC

geofft wrote: post #201

zestyping wrote: post #152

Earlier quoted context omitted.

Slices: My reading of README.md is that Black inserts spaces around the colon, is that right? Almost none of the Python I've seen in 20+ years is written that way. The tutorial and documentation on python.org don't use spaces around the colon, and it is extremely rare in the standard library (out of over 1100 slice expressions that have operands on both sides of a colon, I count 10 that use the extra spaces). Quotes:…

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…

m[a+1:b] and f(x=y+1) are weird corner cases of Python formatting.

I usually avoid this problem by adding extra parentheses:

  m[(a + 1):b]
  f(x=(y + 1))

Re: Black: An uncompromising Python code formatter

#228

Post by cup-of-tea » Sat, May 26, 2018, 11:28 AM UTC

zestyping wrote: post #68

This is great except for the enforcement of double-quotes around all strings and spaces around slice operators. These two choices contradict the standard Python documentation, most of the standard library, and the behaviour of the interpreter itself. When the language itself has an established convention, Black should follow that convention, not fight it. These two weird choices just generate needless churn, which is…

Coming from a C background I always stuck with double quotes for strings. Single quotes are used for characters in C. I think double quotes are better anyway because an apostrophe is much more likely to turn up in a string than a double quote itself. I rarely have to manually escape quotes inside strings.

Re: Black: An uncompromising Python code formatter

#229

Post by cup-of-tea » Sat, May 26, 2018, 11:32 AM UTC

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…

As usual the practice can be traced back a long time to Lisp. It's completely expected that Lisp code will be formatted in the standard way. This isn't a Go thing.

Re: Black: An uncompromising Python code formatter

#230

Post by cup-of-tea » Sat, May 26, 2018, 11:36 AM UTC

waleedka wrote: post #113

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…

One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded stri…

That's pretty standard in libraries that do i18n (like Qt, for example). It's a very good practice IMO. Not only does it enable i18n, it means you can easily collect every user-destined string and check it for things like forbidden words etc.