pre-commit/black is getting in the way too much

It is annoying to get interrupted with something like:

% gc
[WARNING] Unstaged files detected.
[INFO] Stashing unstaged files to /home/user/.cache/pre-commit/patch1583628686.
black....................................................................Failed
- hook id: black
- files were modified by this hook
[20+ lines deleted]
[INFO] Restored changes from /home/user/.cache/pre-commit/patch1583628686.

to see that black did turn it into something less readable (since it does not recognize “exploding commas” with function calls):

-    result.stdout.fnmatch_lines([
-        'E       assert False',
-        '*- Captured stdout call -*',
-        'hello',
-    ])
+    result.stdout.fnmatch_lines(
+        ["E       assert False", "*- Captured stdout call -*", "hello",]
+    )

Therefore I think it would be more sensible to either exclude black from the pre-commit config altogether, or not to recommend installing pre-commit in the first place.

I think it is fine to enforce checks on CI, but that could/should be limited to flake8 etc only, and black could be run then in the release process.

Black is meant to have consistent output for things being committed, but it does not help if you have to add # fmt: {on,off} (after being interrupted), or just accept that it is less readable etc. I.e. in the second case it certainly causes code to be less readable / and more affected to diff churn (when tests get hardened/changed with regard to their output).

[RonnyPfannschmidt]

i consider black a integral part of keeping certain review overheads low, i’m not going to agree with removing it

[nicoddemus]

Sure, sorry, but either way you are definitely free to uninstall pre-commit and run tox -e linting manually, but we should not recommend that in general, as people often get it wrong.