Proposal: Use "black" for formatting

[apdavison]

Black is "The uncompromising code formatter. By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from [pep8speaks] nagging about formatting. You will save time and mental energy for more important matters."

I personally don't like all the decisions that Black makes about formatting, but I do like the idea of not worrying about formatting when writing, and when reviewing code. You can set it up as a pre-commit hook so the styles are applied automatically.

This article thinks Black is a good idea, this article thinks Black is not so great.

This PR is not intended to be merged, necessarily, but it demonstrates the effect of running black -l 99 on the current code base.

What do you think?

[samuelgarcia]

Hi Andrew,
I must admit that I don't have strong opinion of which linter to use.
I totally trust you on this.

[JuliaSprenger]

Hi @apdavison @samuelgarcia,
this is indeed a tricky question as I think the code style within the package should be as consistent as possible. However as @apdavison, I am also not happy with some of the style decisions black is taking, which might potentially result in an accumulation of # fmt: off statements in our code.
Looking at context of pep8 mentions in the comments and commits in this repository it might however be a good idea to get rid of the pep8 overhead. So in total I would currently tend towards integration of black.

[JuliaSprenger]

I had another look at this topic and found this comparison here: https://www.kevinpeters.net/auto-formatters-for-python Maybe we can agree on one of the yapf modes and add an autoformatting workflow. @apdavison Should we give this another try?

[apdavison]

black seems to offer too little configurability. Considering trying yapf