Use black for code formatting

[basnijholt]

No description provided.

[akhmerov]

Coincidentally I also checked black recently. It's a decent idea. Sometimes its default formatting is not very good (for instance I stumbled upon psf/black#824), but the advantage of never needing to bother with minutia could outweigh this drawback.

[akhmerov]

Is it possible to separate black and other linters from the rest of the pipeline?

[basnijholt]

We can create a separate lint-pipeline.yml but why would we do that?

[akhmerov]

We can create a separate lint-pipeline.yml but why would we do that?

So that it is clearer for people submitting the code what goes wrong. Also so that we may ignore it or apply it on our own.

Also if we're using black, we need to document it and make a pre-commit hook.

[basnijholt]

We could use https://github.com/pre-commit/pre-commit for that.

[basnijholt]

So that it is clearer for people submitting the code what goes wrong. Also so that we may ignore it or apply it on our own.

But if the tests fail one can just click on the details and see what failed exactly, which is what one needs to do if something fails anyway.

[akhmerov]

Well, for example right now the authors check failed but we don't see that.

[akhmerov]

pre-commit seems OK (if only a bit of an overkill for a pure python package with one hook so far), but my point is mainly that we should document how to use black in e.g. CONTRIBUTING.md

[basnijholt]

A relevant issue in black psf/black#148.

[basnijholt]

@akhmerov I've added pre-commit with flake8, black, and white-space fixers.

I've fixed all flake8 issues too and added this to the "Development" section https://github.com/python-adaptive/adaptive/pull/191/files#diff-88b99bb28683bd5b7e3a204826ead112.

[basnijholt]

These settings are like this to make black compatible with flake8

[akhmerov]

LGTM

[basnijholt]

I am merging into stable to avoid many merge conflicts in the future.