Introduce black formatting in the codebase

I did not see any other issue related to this.

Black has allowed many open sourced project I worked on to gain more contributors, notably because people don’t fight over formatting, and they don’t fight with the CI to match the style imposed by a tool that doesn’t autocorrect the code (pycodestyle or flake8).

We have two ways to introduce black to this massive codebase if we wish to do so:

1. We ignore all existing files and impose black on new files to avoid backport issues and conflicts in PRs
2. We format the whole codebase at once and ignore the commit (for git blame) with https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html

Are the maintainers open to such a move?

[mattip]

Maybe this should all wait until after we drop python2.7. I think the potential for problems outweighs any perceived benefits from formatting this very complicated and old code base.

[eli-schwartz]

I think that’s exaggerating it.

The converting of consistent single quotes to consistent double quotes is meh and less “but I wanted it so”.

The mangling of function signatures across multiple lines, and converting this:

def foo(....) -> ...:
    do_things()

to this:

def foo(
    ...
) -> ...:
    do_things()

is literally unreadable to me, and it is indeed so bad that I’m so unhappy that I’d convert it all back.

Surely there must be a python code formatter that solves formatting woes without making code unreadable in the process. yapf exists, at least. I haven’t personally tried it, so I cannot judge, unlike black which I’ve tried and judged. 😛 I haven’t tried blue either (seems to be black, slightly modified for single quotes and some configuration?) Seems interesting.

Of course, my opinions as a rare contributor may not be all that representative. But there you have it, for what it’s worth.