psf

black

Python2018–2026

psf / black

black

The uncompromising Python code formatter

Developer Tools

Explore on GitHub Read Hacker News discussions

79Distinct people

83Mentions

3Explicit recommenders

42.2KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

The uncompromising Python code formatter

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I don't see the black python formatter[0] mentioned. I use it for all of my projects and I love it as I prefer not to have a linter distract me while I type. You can see a…

reportgunner used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

pylint-dev/pylint · linked in 3 of the same discussions
asottile/pyupgrade · linked in 2 of the same discussions
pre-commit/pre-commit-hooks · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year83 dated mentions

Observed mentions: 2018-03-14 21:57:08 UTC to 2026-09-30 22:50:00 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	11	5	6
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	16	2	14
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	9	0	9
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	14	3	11
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	16	3	13
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	3	0	3
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	7	1	6
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	0	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	5	1	4

What Hacker News says

16 sources

dedoussis·Nov 4, 2022

It's funny that geohot/tinygrad chooses to not meet the PEP8 standards [0] just to stay on brand (<1000 lines). Black [1] or any other python autoformatter would probably 2x the lines of code. [0] https://peps.python.org/pep-0008/ [1] https://github.com/psf/black

In Tinygrad: A simple and powerful neural network framework

intrepidhero·Sep 27, 2022

I like the concept of using mypyc to leverage type hints to compile python. But I was pretty frustrated recently when I got bit by a bug in mypyc[1] while trying to use black. Especially since I wasn't using mypyc myself and so didn't realize it was even in my dependency tree. Beware adding "alpha" quality software as a dependency to your supposedly production ready tool. [1] https://github.com/psf/black/issues/2846

In Making Python fast – Adventures with mypyc

LittlePeter·Aug 31, 2022

> We still don't have format selection And you never will. From https://github.com/psf/black: Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

In Ruff – a fast Python Linter written in Rust

recuter·Apr 4, 2022

This is why the good lord gave us: https://github.com/psf/black Import line is actually improved with this commit. LGTM, ship it. We now return to your regularly scheduled bikeshedding.

In Tinygrad

rcv·Feb 8, 2022

Black is a tool that can reformat Python code. It's remarkable for it's lack of configuration. https://github.com/psf/black

In Django: Reformatted code with Black

punnerud·Feb 8, 2022Submission

Black – The uncompromising Python code formatter

2 points · Open discussion

pinkman68419·Feb 8, 2022

The etymology of black is "any color you like, as long as it's black" [0]. The whole point is that it's _not_ configurable. [0] https://github.com/psf/black#readme

In Django: Reformatted code with Black

BerislavLopac·Jan 30, 2022

I'm a huge fan of black, and have been using it in most of my projects for a long time. That being said, my biggest gripe with it is that it has at some point started reformatting docstrings [0] in addition to the code -- strictly following PEP 257 [1] -- without any way to disable that behaviour. While I understand the desire to standardise, docstrings are not executable code, and should be allowed more flexibility when it comes to formatting. [0] https://github.com/psf/black/issues/1779 [1] https://www.python.org/dev/peps/pep-0257/

In Black, the uncompromising Python code formatter, is stable

sciyoshi·Jan 30, 2022

Congrats to the black team on this release, and thank you scrollaway for your fork. We are in a similar position where we are (for various reasons) stuck on using tabs for an existing project. Luckily it seems like there might be some movement on this front where the maintainer team is at least more receptive to reopening this conversation: https://github.com/psf/black/issues/2798

In Black, the uncompromising Python code formatter, is stable

ublaze·Jan 29, 2022

I remember we migrated 2+ million LoC to being formatted by Black at Dropbox. Our Livegrep instance with a custom Git blame implementation always crashed at the commit made to do the migration :-) We had to pause our merge queue because we didn't want to run into conflicts, and I remember the `git push` ended up taking a while. There was only one change that we had to make to Black to get it working on our codebase - https://github.com/psf/black/commit/024c9cab55da7bd3236fd887... Glad to see it's now stable.

In Black, the uncompromising Python code formatter, is stable

ambivalence·Jan 29, 2022

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

In Black, the uncompromising Python code formatter, is stable

pauloxnet·Jan 29, 2022Submission

Release 22.1.0 · Psf/Black

1 points · Open discussion

collinmanderson·Jan 29, 2022Submission

Python's Black is finally non-beta software

4 points · Open discussion

danjac·Jan 12, 2022

No problem with Black per se - it's my default linter - but latest inclusion with IPython 8.0 seems to break in a Docker environment: Generating grammar tables from /usr/local/lib/python3.10/site-packages/blib2to3/Grammar.txt Writing grammar tables to /root/.cache/black/21.12b0/Grammar3.10.1.final.0.pickle Writing failed: [Errno 2] No such file or directory: '/root/.cache/black/21.12b0/tmpx51kjom5' Generating grammar tables from /usr/local/lib/python3.10/site-packages/blib2to3/PatternGrammar.txt Writing grammar tables to /root/.cache/black/21.12b0/PatternGrammar3.10.1.final.0.pickle Writing failed: [Errno 2] No such file or directory: '/root/.cache/black/21.12b0/tmp80hsbuff I believe this is the issue: https://github.com/psf/black/issues/1143 Not entirely clear what the reasons are for adding the Black dependency

Read the rest

to IPython....

In IPython 8.0

that_guy_iain·Jan 4, 2022

> that's because the UX for github PRs sucks. Use Gerrit instead. It's not as pretty but it's super productive. That won't affect the quality of what people find and comment about. > that's not a problem caused by code review, it's caused by people who don't know how to work with others (or otherwise simply refuse to). to the degree that the code review process shines a light on this, that's good news, because that's a people problem that should be fixed. You say that like fixing people is an easy thing to do. It's the hardest thing to do. And the fact I've seen this at so many companies/teams leads me to believe that it's an extremely common thing. > when you look at a code review and you see problems in what's there, catching them in the code review is great, because that means less chance of having to fix it later. > if you see a code

Read the rest

review and nothing's wrong with it, you just approve it. sometimes you can note things as "nits", meaning, fine for now but maybe next time do it this way. Yea... Those aren't getting done at 9/10 companies. They're getting ignored. > syntactical style and formatting should be automated, if not with tooling that actually rearranges the code in that way (e.g. [black](https://github.com/psf/black) for Python) then at least including well tuned linter rules. We use black, my own zimports tool for sorting imports, flake8 with four or five plugins as well as "black check", so we spend exactly zero time dealing with anything to do with style or code formatting, including having to even type any of it. if people are fighting over code style then there need to be tools that lock all of that down so there's no disagreements. Yea, we have those, I still get asked for stupid ass code style changes at every company for the last 8-years. Why? Because people can spot them and understand them. But can't code review for shit. They can't understand the idioms for the programming language, they can't understand how certain paradims work, they don't pay attention to root causes of bugs, they don't know how to design a database, they don't pay attention to performance, etc. I would say 80% of the industry can't code review for crap. And that is the biggest problem and because they can't do that all the other problems are just symptons. > I work on the Openstack project and that is where I learned to do code review with Gerrit, it is completely essential for large projects and is an enormous productivity enhancement. Decades ago before CVS was even invented, the notion of using source control seemed crazy to me. That position was obviously insane, even though we were stuck using Visual Source Safe at the time. That's how it feels to me to be doing a real project today without code review and formatting tooling in place. Like even for myself, if working alone, for a large project with lots of changes I still use a code review tool, just to review myself. This doesn't dispute or refute my point. It merely says in some cases it's used well. It doesn't remove the fact that majority of the time it's cargo cult and the majority of people who code review can't code review for crap or the fact that a high percentage of people just skim code review.

In No code reviews by default

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.