Black: An uncompromising Python code formatter • Hacker News Board

Re: Black: An uncompromising Python code formatter

#161

Post by ben509 » Fri, May 25, 2018, 10:19 PM UTC

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…

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

Re: Black: An uncompromising Python code formatter

#162

Post by jsmeaton » Fri, May 25, 2018, 10:24 PM UTC

I wanted to add a bit of positivity and mention that I'm really liking how the black project is approaching problems. For example, a few people brought up fluent interfaces[0] as an issue. There were many opinions about the right and wrong thing to do, but discussion got to a very pragmatic decision I feel.

Then there were requests to add command line arguments specifically so that tools could integrate with black that were added almost immediately.

Congrats on gaining so much traction so quickly, and thanks for listening to users (when it makes sense).

[0] https://github.com/ambv/black/issues/67

Re: Black: An uncompromising Python code formatter

#163

Post by ambivalence » Fri, May 25, 2018, 10:27 PM UTC

hrez wrote: post #135

What's with python 3.6 requirement? - Major stable distros are at python 3.5. So I can't even try it without messing with system python or OS.

It's open source software created by a volunteer. Using the latest version of Python lets me leverage features which help me focus on the problem at hand. f-strings, pathlib integration, the latest typing module, and so on.

I'm sorry this makes using my tool harder for you but I'm sure there is an easy way for you to install Python 3.6 without destroying your system Python. There's Homebrew for macOS, deadsnakes for Ubuntu, EPEL for RedHat, and so on.

Re: Black: An uncompromising Python code formatter

#164

Post by ben509 » Fri, May 25, 2018, 10:27 PM UTC

curtis wrote: post #3

> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?

We get a fair amount of code from non-developers, and it invariably looks like hot garbage. Having something that auto-cleans it is a godsend.

Re: Black: An uncompromising Python code formatter

#165

Post by nicpottier » Fri, May 25, 2018, 10:39 PM UTC

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…

We did this as well, but I think the benefits of black and auto-formatting outweigh losing this convention.

Re: Black: An uncompromising Python code formatter

#166

Post by Shish2k » Fri, May 25, 2018, 10:43 PM UTC

zestyping wrote: post #152

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…

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:…

> My reading of README.md is that Black inserts spaces around the colon, is that right?

I can't speak for the readme, but:

    $ cat test.py
    x = [1,2,3]
    print(x[1: 3])

    $ black test.py
    reformatted test.py

    $ cat test.py
    x = [1, 2, 3]
    print(x[1:3])

Re: Black: An uncompromising Python code formatter

#167

Post by ubernostrum » Fri, May 25, 2018, 10:45 PM UTC

sametmax wrote: post #141

klodolph wrote: post #114

Earlier quoted context omitted.

When I read that line in the documentation, it hurt a little. I'm going to be honest here. I did not feel good with someone saying that an 80-column limit is just there to pad my paycheck, rather than an informed decision I made. I realize that it was tongue in cheek, but it still felt bad.

If that hurt you, you need bigger problems in life.

I like a line length rule because I use an editor that can show me multiple files side-by-side, and keeping things to a certain length ensures that I can productively do that.

And my terminal happens to be around 240 characters wide for the font size I use and the size of my laptop's screen, which means if I limit to 80 characters or less I can snugly fit three files, or if I set to 100 I can get two with some breathing room.

Plus, if a line really is going over those lengths, then it's often a code smell: maybe I've got code that's too complex and ending up deeply-nested, or maybe I've got functions or methods taking way too many arguments, and hitting a line-length rule will warn me about that.

Re: Black: An uncompromising Python code formatter

#168

Post by zbentley » Fri, May 25, 2018, 10:51 PM UTC

0xffff2 wrote: post #40

curtis wrote: post #3

> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?

I'm fine with ceding control right up until the formatter does something I don't like for no good reason. For languages like Rust, where there is a single format convention that is closely tied to the language (via rstfmt), I am okay with this kind of forced standard. For something like Python, C++, or Java where there isn't a single "winner" for format guidelines, there's virtually no chance that I would embrace som…

> right up until the formatter does something I don't like for no good reason.

Hand-formatting. You are describing formatting code by hand.

Re: Black: An uncompromising Python code formatter

#169

Post by zbentley » Fri, May 25, 2018, 10:57 PM UTC

foxhop wrote: post #145

This is so cool. I like all the choices and will be adding it to my workflows for my personal projects.

Choice. There is only one (line length). And I think that's a good thing. Which were you referring to?

Re: Black: An uncompromising Python code formatter

#170

Post by fishywang » Fri, May 25, 2018, 11:14 PM UTC

ambivalence wrote: post #36

abakus wrote: post #28

I like the spirit of it, but the implementation seems to contain too many exceptions (e.g. trailing comma, whilespaces around :). This problem is not unique to Black, it is actually too common for most auto-formatters. I usually prefer a set of dead-simple formatting/styling rule, easier to enforce, lower cognitive load.

What don't you like about the exceptions? The code and the documentation would both be simpler without them. They are there because the end result is closer to what a human would do in those situations. And the two exceptions you mentioned are ones you will also have to make if you want to stay PEP 8 compliant (pycodestyle's E203 is invalid inside slices) and you want your code to execute on Python pre-3.6 (where you…

> where you can't add trailing commas to calls and signatures containing args and kwargs
I think that's signature only. You don't have problems with calls:
$ python3.5 Python 3.5.5 (default, May 17 2018, 07:04:26) [GCC 7.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def foo(*args, **kwargs): ... print(*args, **kwargs) ... >>> foo( ... 'abc', ... ) abc >>>
The argument black made about not adding trailing comma is also quite unconvincing to me:
> Unnecessary trailing commas are removed if an expression fits in one line. This makes it 1% more likely that your line won't exceed the allotted line length limit. Moreover, in this scenario, if you added another argument to your call, you'd probably fit it in the same line anyway. That doesn't make diffs any larger.
Who cares about the 1% chance of not exceeding the line length limit? If you really care about that, use one-per-line style, not all arguments in one new line.

Permalink View on HN Reply on HN Top