Automatic code formatting

[shyba]

We want something like gofmt for python. We want to minimize changes to existing code while defining a style we agree to. Ideally it should automatically format files on save (PyCharm integration would be great) and/or as a precommit hook.

One option: https://github.com/google/yapf

From @eukreign on Slack: but to elegantly switch to yapf would require:

1. defining a new config that's as close to current code as reasonable
2. running the converter and adding a comment to any datastructure that is uglified by yapf

whoever takes on this project should be willing to carefully skim through the changes yapf makes to make sure it's not uglier (at least not too much uglier) than before

[Bhupesh-V]

I think black can be a great choice. the python community is slowly accepting it. It's PEP8 compliant as well

[Bhupesh-V]

Leading to this I checked lbry-sdk on lgtm.com seems there are a lot of issues related to Unused Imports etc. I suggest we could add pylint to catch this kind of stuff, if code quality is important

[belikor]

I hate black. I don't like it because it tends to produce code with parentheses in different lines, like in a C style, which tends to look bad in Python.

Regular Python

def some_function(arg):
    return

With black

def some_function(
    arg
):
    return

I call it "sad style" because of the final sad face that is produced ):

Maybe black can be configured to avoid this, and adjust some properties but I have never tested it.

My preferred style is the one used by scientific libraries like numpy and scipy. If you use the Spyder editor, it automatically checks your code as you write, and it gives you the best formatting suggestions according to pycodestyle (optional dependency). Basically following those suggestions is enough to have a consistent style; it becomes second nature after a while.

[belikor]

Compliance with Python's PEP8 can be checked with flake8.

flake8 --ignore=E226,W503 --max-line-length=80 file.py

We may ignore certain errors and warnings.

• E226: spaces around arithmetic operators *, /, +, -; sometimes we don't need a space.
• W503: break lines before a binary operator like and and or. The W503 warning will be changed in the future so we can ignore it for now.
• Line length is typically 80 characters, but of course, we could be flexible; 100 is common as well.
• See the meaning of the error codes in the pycodestyle documentation. As I mentioned, this style is automatically checked by some editors, like Spyder.

A good way to test entire folders for compliance is to run the following command.

find lbry/ -name '*.py' -exec flake8 --ignore=E226,W503 --max-line-length=80 '{}' '+'

[glunkad]

Hi @shyba , I'm interested in contributing to this issue, so before I start working it, would you mind sparing your time explaining what the issue is about and pointing me to some resources to get started.

[ghostp13409]

Hi @shyba, I'm interested in contributing to this issue, is it still required?