Black, the uncompromising Python code formatter, is stable (pypi.org)

Congratulations. I'm a Python developer of 17+ years and Black is truly a huge blessing in the Python ecosystem.

That said, I'm a little sad to see it's gone stable without adding support for tabs, which would be extremely simple to add at this point (cf. https://github.com/jleclanche/tan/commit/e23c038167528bdacdd...). I have a lot of people using this tab-capable fork, that I did not advertise anywhere.

Łukasz seems to have a personal grudge against tabs which may be why the issue for tab support was closed early on, but there's a plethora of good reasons to support it behind a flag. I don't want to rehash those arguments here on HN but you think you could re-think the approach a bit?

I'd be happy to do a PR if it's not getting rejected right away with "no discussion allowed" like the last one was (before Black was moved to PSF maintainership).

> The default style is updated yearly.

I'm hoping there will be minimal or even zero style based commits, excepting those related to new Python features. It wouldn't be very Black-like to force a commit of a potentially enormous size on users of the library every year. Probably something you're already thinking about.

I was apprehensive about taking our legacy codebase Black, but zero regrets. Thanks for your work!

Uniformity, presumably

I prefer them too. Makes it easy to notice than single ones. It's just a personal preference, there's no big logic behind it.

Because "don't" is easier to read than 'don\'t'

     print("\"Hello\" he said")

     print('"Hello" he said')

A couple of possible reasons:

* Double quotes are more visible, especially for triple quotes.

* It makes it easier to have text without having to manually escape apostrophes.

Because most commonly used languages use double quotes, not single quotes, for string literals. Some languages can use both, either interchangeably or with slightly different semantics, but others either uses single quotes for other purposes, or do not use them for anything at all. Therefore, double quotes for strings look more normal, so to speak, in source code.

  query = "SELECT column_a FROM a_table WHERE column_b = 'foo';"

  query = 'SELECT column_a FROM a_table WHERE column_b = \'foo\';'

  query = 'SELECT "columnA" FROM "aTable" WHERE "columnB" = \'foo\';'

  query = "SELECT \"columnA\" FROM \"aTable\" WHERE \"columnB\" = 'foo';"

  query = "SELECT columnA FROM aTable WHERE columnB = 'foo';"

It's a tic for me too, as I always prefer '.

But to be fair I think it's because 1. Double quotes are ""universally"" strings in other languages 2. Having apostrophes gets annoying.

The great benefit really is that I can write single word strings just fine, and black will adjust it for me. I get my cake, and so do the others.

This was decided very early in the project, the discussion can be read here: https://github.com/psf/black/issues/51

It’s easier and faster to differentiate between “ and ` than between ‘ and `.

This is simple: the default is picked, so now no one has to argue about it.

Arguing over Black formatting choices is a little ironic, isn’t it?

The whole point is that they’re all arbitrary so just let the defaults win, and adjust yourself instead.

In some languages single vs double has different functionality.

That was the thing that bugged me at first, but other people on my team loved it. Some things bugged other people on my team, even though I love them. If a tool can manage to annoy everyone about the same amount, but in different areas, it’s doing something right.

And while it’s still kind of strange that `a = “foo”` looks different than `repr(a)`, after a while of using Black I don’t notice it anymore.

Try nero from PyPI instead, I’ll upgrade to stable shortly.

Additionally, standardizing all quotes makes searching for a specific string literal across a codebase easier, since you don't need regex to match against both quote types. Once you've decided to standardize strings, it doesn't matter much which one you pick.

Personally, I still type single quotes in almost all cases, and just let Black reformat to double quotes to save shift key presses.

The other way around (converting double quoted strings to single quoted ones) would be more understandable, as that is what str.__repr__ prefers:

    >>> "string"
    'string'

I sense a bloated ego of the author in Black's decisions -- to contradict with the language's preferred formatting style.

There probably is, if you use another formatter that isn’t Black.

There is: -S, --skip-string-normalization Don't normalize string quotes or prefixes.

Funny that this is a common reaction against opinionated tools: "I wish there was a configurable option to apply my opinions"

But the whole idea is that you should learn to suppress your ego and let the tool be the one dictating stylistic choices...

Like the sibling comment mentions:

Dusty Phillips, writer:

"Black is opinionated so you don’t have to be."

Try nero from PyPI instead, I’ll update it to this stable release shortly.

That will be reverted in the next version, i.e. it'll be optional.

“the next release will likely revert it”

— Matthias Bussonnier, https://github.com/ipython/ipython/issues/13463#issuecomment...

Here here! Same.

I love it even though I dislike quite a few of its formatting rules.

Because the only thing worse than a slightly wonk formatting convention is spending any time at all implementing, arguing about, or otherwise worrying about formatting conventions.

The problem I have with it is that, to me, these are super readable:

    x = [ 1, 2, 3 ]
    y = { 'a': 1, 'b': 2 }

Whereas these are not:

    x = [1, 2, 3]
    y = {'a': 1, 'b': 2}

To me, declaring inline lists and dicts without the leading and trailing space makes it more difficult to see what the data structure is, and what it contains. This is especially true when you have lists or dicts declared inline as arguments to functions, e.g.:

    my_function_call([ 1, 2, 3 ])

versus:

    my_function_call([1, 2, 3])

While it's generally not good style to declare data structures inside function calls, at least with the space it's still somewhat apparent what's happening, whereas without the space it just looks like three positional arguments. I love the idea of black, but in practice I'm not going to use something that changes my own code into something that's more difficult for me to read.

  Foo<Bar,Baz> value = some.method (1, 2, 3 + 4) ;
  // or with no parameters:
  value = some.method() ;

    my_function_call( [1, 2, 3] )

Agreed. My only grievance with Black was that it was really slow compared to gofmt or rustfmt, but that’s a perennial problem with Python tooling.

Is there a way to pass hooks with a repo, or do you have to give people instructions about how to install them and hope they do it?

Before I introduced Black in my workplace, all code reviews were peppered with stuff like "should be indented", "use single quotes" etc. Made it impossible to talk about the stuff that actually matters.

When introducing it there was some resistance. There's always that one guy who tried it once and it reformatted that perfectly hand-formatted function. My answer to them was suck it up. In a tiny fraction of cases Black might make a suboptimal choice, but the rest of your code is so shit it outweighs this negative by 100x.

You can disable formatting for specific lines or blocks with `# fmt: off`

https://black.readthedocs.io/en/stable/the_black_code_style/...

Do it all in one commit.

Then put that commit's (full) sha in a file named something like .git-blame-ignore-revs

Then `$ git config blame.ignoreRevsFile .git-blame-ignore-revs`

Prettier is the closest I've found for JavaScript.

Check out Prettier

“Standard” was popular for a while but fell out of vogue. Prettier is the one to reach for these days. I’m a big fan

prettier [1] and google-java-format [2]

[1] https://prettier.io/ [2] https://github.com/google/google-java-format

To add onto this, I also found that Black works as a nice heuristic indicating to split up code when the formatted output isn't "pretty" into separate lines.

It's been at least a decade since I've not used an autoformatter on every piece of code ever. I didn't realize there were people who worked at places without autoformatters still.

Had a similar experience when I used rustfmt (which led me to trying black). I was used to formatters that over formatted, removing newlines used to dilineate sections of code, etc. I tried rustfmt when learning Rust because I figured id learn adopt standard practices.

It was revolutionary. I went from formatting as I went, even for prototyping to throwing code at my editor and letting rustfmt fix it. Big difference in productivity.

To clarify, the slow git push was likely custom pre-receive hooks being slow.

`another_really_really_long_element_with_a_unnecessarily_long_name_to_describe_what_it_does_enterprise_style` hahahahaha, I love that test case.

When I switched the company to Black, I reformatted the whole repository history with it. Every developer had to clone the repository again and reapply their local changes to it, but in the end it was a good choice because "blame" still works perfectly since we don't have one big reformatting commit.

Pretty sure Black prefers double quotes in the main case, but what are “fluent interfaces”? Go is pretty great though, I completely understand the envy! :)

Yeah, and I wasn't aware there was anything to format. This is Python after all, code style is enforced by compiler lol.

> If you don't want to discuss "taste" questions, then just don't, it doesn't matter what option you pick. If it is an important question, then you should debate it.

I'm personally glad to see Python development come to the same conclusion enforced by Go's opinionated tooling.

That is: style questions are almost always unimportant to producing value, but teams still waste excessive time on them because of the engineering tendency to bikeshed triviata.

I think the general consensus of many people, myself included, is that it doesn't matter what the specifics are, as long as they're being applied consistently. Beyond that, it's a question of optimizing the cost/benefit ratio.

The problem with most things that have to be applied manually is that they're also applied inconsistently. It's like Hungarian notation. Over time, it becomes pure noise: you can't rely on it, especially when reading someone else's code, so it's safer to just ignore it. At which point, the convention's cost/benefit is approaching infinity, because its denominator nearly zero. So I'm not sure I care if the absolute cost is small. It's still an almost complete waste of effort.

The only place I've ever seen manual conventions applied consistently enough to be useful in a sustainable way is when someone's carved out their own private silo of code that is mostly only touched by them.

> If you don't want to discuss "taste" questions, then just don't, it doesn't matter what option you pick.

Exactly, it doesn't matter what option you pick, as long as everybody picks the same option. Enter opinionated code formatters, because otherwise how do you do it?

> Personally, I don't understand the appeal of opinionated code formatters. If you don't want to discuss "taste" questions, then just don't, it doesn't matter what option you pick.

I think the appeal is that it avoids the discussions entirely (i.e. if it doesn't matter what option you pick, why even have the option? Particularly if these options will mean you divert away from the standard python style guide, which has been trying to standardize these choices for years so that codebases have similar rules.)

i.e. if your org has inconsistent python formatting between different independently-operating teams, it's easier to enforce PEP 8 than start a load of pointless arguments about what good looks like.

I can stop discussing taste issues, but it doesn’t prevent others from debating what the proper style for my PR ought to be, meanwhile I can’t merge my PR.

> I think you can convey meaning with subtle code style differences.

Yes that's very true, but, and now comes the big but - if you're working in a project with dozens and dozens of other devs, you will necessarily see all kinds of weird formatting. And this is where an opinionated formatter shines. It doesn't matter how many people work on your project, what the churn-rate is or if the guy that just started yesterday already read the code-formatting guidelines or not - the formatter will just take care of it and remove all hassles surrounding that topic. And this only at the price of opinionated formatting which I may or may not like - a price that I likely have to pay either way, because there's no way that everybody shares the same opinion about formatting in the first place.

I recommend to give opinionated formatters a try, if you haven't already. I know plenty of folks who were initially against it but eventually came around it because it made life a lot easier: No more discussions about formatting on PRs, no more tabs vs space wars, everything's already settled and automatically taken care of.

> Personally, I don't understand the appeal of opinionated code formatters.

Opinionated code formatters mean that opinionated coders with different preferences on a team don't produce (or at least produce less) noise in diffs.

The reason I like black is the most opinonated folks have WEIRD opinions.

You see that here.

Things like a = [ 1, 2, 3 ] when 90% of the world is a = [1, 2, 3]

These folks will spend hours / days try to force weird approaches.

Sometimes they are obviously wrong. But it's annoying to have to fight over it. Something like black saves you the hassle and the WEIRD local coding rules someone comes up with if you are on a project with them.

> convey meaning with subtle code style differences

Why? This is exactly why we need autoformatters :-) if you're on a team, you should be conveying meaning with variable names, comments, and structure. If it doesn't show up in the syntax tree, it doesn't have meaning. Consistency always wins because it elevates everyone's ability to read the code.

There's more to it than the social aspect though: putting effort into manually moving around characters in a text editor is not the best use of mental bandwidth. My experience (and that of many I know) is that formatters help you code faster with less bugs by letting you focus on the higher-level structure of the problem NOT on the minutiae of where each punctuation mark should live. If your code is syntactically correct, the autoformatter will make it look "right" and you don't have to think about consistent formatting at all. If it's not syntactically correct, you set your editor to autoformat on save and you get immediate feedback. So it's not just about consistency, it's also a productivity aid.

I understand having strong opinions about the "right" code style. Personally, I dislike the double quotes in black. So I type single quotes and let black do its thing on save. What I type does not need to be what I commit (so long as they both compile to the same AST)! I don't want to waste time debating formatting details in a PR, and I certainly don't want to interrupt my coding flow to manually perform the labor of shuffling ascii chars around when there is fully automated solution. I can't think of a single scenario where my personal style preference would outweigh the significant advantages I've seen from autoformatters.

Sounds like you actually are very opinionated about your coding style, so it's both totally understandable and yet ironic that you'd begrudge that of others. I've tried hard to internalize that opinions are like assholes, everybody has one and they all stink. My own included.

> Empty lines to delineate blocks.

Use comments to describe those blocks and their meaning, don't just assume everyone is thinking exactly the same as you are about the code organization (hint, they probably aren't). Where you see a bunch of logically separated blocks of operations I might be new to the codebase and just see a bunch of unnecessary whitespace. Describe what's being organized and why in comments.

  def foo(a,b,c):
    var x = 40
    var y = None
  
    bar()
    
    return x * b

Ye I don't understand it either. Why would you want some automated Whitespace Hitler telling you what to do. You can't even select between tabs and spaces for indentation.

Not that I don't appreciate the shoutout (I'm one of the developers of pip-audit), but what's the connection? Is it because black is installed via pip?

5 upvotes generate a pro tip: have your CI run black --check against the code you want formatted. That way different devs can run the formatting how they like (in tox; in a pre-commit hook; in IDE; on the command line) and CI just enforces that it happened.

Unfortunately Black will reformat code which has only been indented/outdented, causing false diffs even with "ignore whitespace changes".

Sort of why I think Go got it right with gofmt. Its not as strict as it could be but all Go looks more or less the same and it’s because it was built into the language

Too many people have too strong opinions on the subject. Some things are reasonably good ideas, many more are just arbitrary, strict rules prevent doing reasonable exceptions, and an enormous amount of time is wasted discussing the matter.

To me, the point of using code formatters is that you don't have to think/talk about code formatting much at all. As in, there are never annoying comments about formatting in PRs.

A nice bonus is that you end up having uniformly readable code.

Yep, just agree on something, whatever it is, enforce it everywhere and move on. It’s not worth the time arguing. I love gofmt for this.

Arguing over coding standards is harmful, but consistency is a good thing. Best to adopt a standard style guide and limit any debate to deviations and even better to have a tool like Black make it automatic.

It's meant to, as it references Henry Ford's "any color so long as it is black" quip.

> that won't move imports in ways that potentially change behavior of the codebase

How can that be the case? Can't Python imports have behaviour that varies on the time of the day if they want?

An import could monkey patch a basic operation one day but not the next.

Interesting. Now that isort has support for black-compatibility, what’s the main difference with usort?

with these lyrics i might even like the song.

awesome reference!

I agree. I've sometimes found Black's output to be on the borderline of unreadable with the default line length of 80. My team settled on a length of 120 (the only Black config item we changed) and it has largely, though not entirely, solved that problem.

As long as you can easily review code side-by-side with line numbers intact, you're good. The default was chosen for lower resolution 13" laptop monitors to be able to display the Phabricator diff page (think: Github PR review page) without having to wrap any lines.

I agree 80 is too low, but it doesn't have anything to do with 4k monitors, it's just that 80 is too short. Any longer than 120 is not readable imo. Luckily Black lets you change the line length so it's not an issue.