Question: To use black auto-formatter?

[kylepjohnson]

About:

Black is the uncompromising Python code formatter. By using it, you agree to cede control over minutiae of hand-formatting.

Blackened code looks the same regardless of the project you're reading. Formatting becomes transparent after a while and you can focus on the content instead.

Black makes code review faster by producing the smallest diffs possible.

Source: https://github.com/psf/black

Example: cltk/tokenization/word.py, before and after

Pros: Would take a lot of pep8 worries out of our hands. It would hopefully allow us to still use pylint for more meaningful inspection.

Cons: Still in Beta.

Workflow? I don't know when this would be run. It's like gofmt obviously -- would we require (or hope) that each user runs it before code check-in? Or something that the build server could enforce for us? I will read about this.

[diyclassics]

Just started experiment with Black on another project this week—let me get a bit more time with it and I'll weigh in here.

[kylepjohnson]

FWIW I have been using this in the v1 repo, and I think it is fantastic. Using the command isort --recursive . && poetry run black src/cltkv1 tests docs (ex). Have not run into one single problem or accidental breakage.

However perhaps let's wait until the v1 code is ready to do this on the current code base.

[todd-cook]

To make Pylint and Black play fair, it's important to add the disable the "bad continuation" check, see https://github.com/todd-cook/ML-You-Can-Use/blob/master/.pylintrc#L145
With this config, both Black and Pylint can be used; otherwise Pylint will complain about certain pieces of code after Black formats them.

[kylepjohnson]

Good call, looks like I added this sometime back: https://github.com/cltk/cltkv1/blob/master/.pylintrc#L63