The title makes it sound like there may be several options, but I think black is the de facto.
So, why should we use black?
Consistent code base
Never have to worry about formatting ever again, and it looks good
Effectively solves about 95% of flake8 errors for you. No more annoyance trying to figure out why flake8 is yelling at you.
Consistent format => smaller diffs => smaller code reviews
Basically, people are allowed to write code however they want, and then before they commit, just run it through black (either manually or via a pre-commit git hook) and it will take care of any formatting for you.
As far as implementation, the recommended way is to just do one large commit that re-formats the entire codebase, and then use git-hyper-blame or git blame --ignore-rev and co to ignore that commit and still be able to see who wrote what.
The big question is do we accept black’s default or add some of our style changes:
–skip-string-normalization
–line-length = 79
I do have diffs for comparison of
black
black --skip-string-normalization
black --skip-string-normalization --line-length = 79
autopep8 --ignore E241,E731,W503,F405,901,FI12,FI14,FI15,FI50,FI51,FI53 PR 3673
I would strongly prefer to keep at least --line-length=79 if we do this. I’m less familiar with the effects of --skip-string-normalization but almost certainly have less of an objection there.
--skip-string-normalization skips this check, and thus won’t auto format ’ into ".
If you are adopting Black in a large project with pre-existing string conventions (like the popular “single quotes for data, double quotes for human-readable strings”), you can pass --skip-string-normalization on the command line. This is meant as an adoption helper, avoid using this for new projects.