Re: Migrate code style to Black

[donglihe-hub]

What does this PR do?

Migrate code style to Black.

Note: Black is strictly about formatting, nothing else.

1. Add requirement-dev.txt for pre-commit setup (may be moved to requirements later)

The file includes the necessary dependencies for pre-commit. Please install the dependencies under the root directory using

pip install -r requirements-dev.txt

2. Install pre-commit to your local repository

As hooks are a feature of git, pre-commit hooks have to be manually installed to your local repository by executing:

pre-commit install

3. How does pre-commit work?

Every time you make a commitment, the pre-commit hook will examine all relevant files under the current working directory. If any test defined by pre-commit fails, the commit will be unsuccessful (files in the staged area will not be affected).

As we use Black, pre-commit will automatically format all .py files except those in docs/ if it detect your code style violates Black's and refuse your commit (but things in the staged area will remain intact). Afterward, you have to add the auto-formatted files manually and repeat your last commit. This is the expected behavior to avoid any unnoticed changes, and the reason is explained in this issue.

A workaround to the issue is to execute after the commit fails the pre-commit check:

git add -u && !! (not working on my computer. I saw the solution on stackoverflow)

!! means repeating the previous command. For example, if the previous command was git commit -m "some message", then git add -u && !! would be equivalent to git add -u && git commit -m "some message".

Or, you can execute a pre-commit test before committing your changes:

pre-commit run -a

4. Add blame.ignoreRevsFile to your git config to avoid messing up git blame

git config blame.ignoreRevsFile .git-blame-ignore-revs

===================
Get familiar with Black Style using the official Black doc

Test CLI & API (bash tests/autotest.sh)

Test APIs used by main.py.

• Test Pass
  • (Copy and paste the last outputted line here.)
• Not Applicable (i.e., the PR does not include API changes.)

Check API Document

If any new APIs are added, please check if the description of the APIs is added to API document.

• API document is updated (linear, nn)
• Not Applicable (i.e., the PR does not include API changes.)

Test quickstart & API (bash tests/docs/test_changed_document.sh)

If any APIs in quickstarts or tutorials are modified, please run this test to check if the current examples can run correctly after the modified APIs are released.