I believe from memory Django decided to move to using Black back in 2019 [0] but delayed the change until Black exited Beta. Black became none beta at the end of January [1].<p>This was finally merged to the main branch today [2].<p>I suspect there are lots of other both open source and private projects that are also making the change now. This is a show of confidence in Black as the standard code formatter for Python.<p>0: <a href="https://github.com/django/deps/blob/main/accepted/0008-black.rst" rel="nofollow">https://github.com/django/deps/blob/main/accepted/0008-black...</a><p>1: <a href="https://news.ycombinator.com/item?id=30130316" rel="nofollow">https://news.ycombinator.com/item?id=30130316</a><p>2: <a href="https://github.com/django/django/pull/15387" rel="nofollow">https://github.com/django/django/pull/15387</a>
Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits.<p>0: <a href="https://github.com/bwhmather/ssort" rel="nofollow">https://github.com/bwhmather/ssort</a>
I've been using black at work for over a year now. I don't much care for some of the choices it makes, which can sometimes be quite ugly, but I've grown used to it and can (nearly) always anticipate how it will format code. One nice side effect of encouraging its use is how, at least where I work, it was <i>very</i> common to use the line continuation operator \ instead of encompassing an expression in parentheses. I always hated that and black does away with it.<p>What I don't much care for is reorder-python-imports, which I think is related to black (but don't quote me). For the sake of reducing merge conflicts it turns the innocuous<p>from typing import overload, List, Dict, Tuple, Option, Any<p>into<p>from typing import overload<p>from typing import List<p>from typing import Tuple<p>from typing import Option<p>from typing import Any<p>Ugh. Gross. Maybe I'm just lucky but I've never had a merge conflict due to an import line so the cure seems worse than the disease.<p>Edit: Just to be 100% clear: this is python-reorder-imports, not black. I thought they were related projects, though maybe I'm wrong. Regardless, black on its own won't reorder imports.
Reading some of the comments here it's become clear to me that the next stage in the development of auto-formatters is to have the formatter commit the code as a canonical format but to display the code to each individual contributor in the style of their choosing. Thus removing all kinds of arguments about whether 80 or 120 columns is the one true width.
The reason to use Black is the same as Prettier on the HTML/CSS/JS side: forever stop having an opinion on code style, it's wasted time and effort. Any "it's not exactly what we want" comment with an attempt to customize the style to be closer to "what we were already using" is exactly why these things exist: by all means have that opinion, but that's exactly the kind of opinion you shouldn't ever even need to have, tooling should style the code universally consistently "good enough". Which quotes to use, what indent to use, when to split args over multiple lines, it's all time wasted. Even if you worked on a project for 15 years, once you finally add autoformatting, buy in to it. It's going to give you a new code style, and you will never even actively have to follow it. You just need to be able to read it. Auto-formatting will do the rest.
Aside: I love a good linter, but as a long-time Python fan I find it sad that Black has <i>so</i> little configuration (yes, I know, but still) and moreover that it often produces code that <i>no</i> human Python dev I know would write...<p>Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)
Every time I was tempted to do something like this, I hesitated because I didn't want every other line in every file with my name on a single commit, mostly to avoid making git blame harder than necessary. It would be nice if there was a kind of diffing algorithm that can diff code units *syntactically* across history.
worst things about Black:<p>- doesn't respect vertical space - sure, making the code fit on screen might be valuable (though the default width should be at least 120 characters, I mean we're in 2022 after all), but Black does it by blowing up the <i>vertical</i> space used by the code<p>- spurious changes in commits - if you happen to indent a block, Black will cause lines to break<p>- Black fails at its most basic premise - "avoiding manual code formatting" - because a trailing comma causes a list/function call to be split over lines <i>regardless</i> of width
A little shoutout to a alternative Python formating tool <a href="https://github.com/google/yapf" rel="nofollow">https://github.com/google/yapf</a> (developed by Google).<p>The built in "facebook style" formating felt by far the most natural to me with the out of the box settings and no extra config.
I'm so happy that languages are settling more and more on heavy reformatter usage. I'd like to think it was triggered by Go and gofmt. Working on a team where each engineer has their own personal syntax is not fun.
Black is slowly creeping into gofmt-level universality in the Python community and it’s great. The next big milestone is a first-party recommendation by python.org itself.
In general, what are the strategies for large public codebases like this to mitigate supply chain attacks or other source-level attacks?<p>For clarity, I'm hoping to open us discussion about how we're dealing with massive changesets like this that are difficult to review due chiefly to the breadth of it.
The output does look better but this also just looks like every PR for applying a linter / formatter I've ever seen. Not sure why this is news worthy.
So now when you look at the annotated change history all you're going to see is a bunch of changes by the person that reformatted the code instead of the person that wrote it.
I love this except the use of the default black line length of 88. One of the things I appreciate about gofmt is being trusted with deciding on line breaks.
I suggested Black to a team I was on a year ago and one developer hemmed and hawed about how he likes to format arrays or something. I didn't win any friends by pointing out that disregarding those personal preferences is part of why I was recommending it.<p>A year later and it seems to be the default on all projects I'm working on and I'm loving it.
This is such a great news. We've been using Black in the company that I work for the past 3 years or so and it was a game changer for code reviews. Hopefully other open source Python/Django projects will follow the lead.
What's the point of putting linters into CI? Is the point to fail the build if the code wasn't pre-formatted with i.e. Black? Or is the point to autoformat and autocommit the formatted code?
Had a great experience with black. Only thing I did was change its default line length limit to 120 characters (I was regularly dealing with signal names from source data that were about 90 chars).
Do Black and other autoformatters enable significantly more reusable code and computer-generated code? Formatting is certainly not the only or greatest barrier, but if format is standardized across projects, it's easier to plug and play code from outside.
I would really appreciate if there would exist exactly _one_ formatter (without any options) per language.<p>It is way better to deal with ugly formatting as long as it is consistent than with discussions where to put a closing brace/bracket/paren.
“Black” developer refused for a long time to add option to format code with single quotes with very aggressive manners. Now Django devs didn’t see that option for single quotes and code looks unpleasant.