Introduce formatter black

[tabergma]

closes #644

• Introduce formatter black.
• Travis build will fail if the code is not properly formatted.
• Update README on how to use black

[alanakbik]

@tabergma thanks for adding this! I've looked into black and the auto-formatting style seems to work pretty well. The default line-length of 88 seems very small to me (lots of scrolling + monitor half unused) but this is something that Python people seem to like so that's ok from my side. I'd be happy to try this out.

In case the travis build fails due to not matching black formatting, is there a way to either a) automatically execute black formatting, or b) notify the user what they need to do to pass the checks?

[alanakbik]

👍

[tabergma]

You cannot fully automate black as far as I know. However, you can use pre-commit: This will reformat files on every commit you do. I added a section to the Readme on how to use it.

Regarding you point b: We could add a Pull Request template that contains some check points, such as "added tests", "reformatted files using black (check Readme)", "updated documentation". This way, the user would get a hint on what he needs to do and could check the Readme for a more detailed description.

[tabergma]

👍

[stefan-it]

What "strategy" should we use for the current opened PRs? The build for each of them will be ok, but after a merge on master, the build will fail. Should we "force" a rebase on master now, or should we file a follow-up PR later 🤔

[tabergma]

I would suggest merging (not rebase) the master into the PR branches. Depending on the size of the PR there might be merge conflicts to solve. But they should be fairly easy to solve. Afterwards, reformat the code again in the PR branch and you should be good to go.