lint: fix up strict-ish flake8/pycodestyle formatting

[rwe]

NOTE: #80 is based on this branch, and if that merges, this will auto-close.

This consistent-ifies some of the formatting with typical Python styling, incrementally fixing each of the flake8/pycodestyle warnings until none are left, passing with "all rules on". (The one remaining suppression of W503 is disabled-by-default and is required to be disabled for subsequent black autoformatting).

This is a lead-in to https://github.com/qntm/greenery/compare/main...rwe:greenery:black which builds on this to introduce fully-automated formatting and https://github.com/qntm/greenery/compare/main...rwe:greenery:pylint which introduces stricter pylint linting.

With one small exception, this PR touches only formatting and not logic, structure, or names. The small exception is this change:

- f"Could not parse '{string}' beyond index {str(i)}"
+ f"Could not parse {string!r} beyond index {i}"

which, via the !r → repr format specifier, now escapes strings as 'foo\nbar' for a string containing a newline, versus previously including such characters in the message literally.

[rwe]

Man these package versions need pinning:

ValueError: Error code '#' supplied to 'ignore' option does not match '^[A-Z]{1,3}[0-9]{0,3}$'

No error for me on flake8 5.0.4 but who knows what CI's running…I'll fix.

[rwe]

And by "who knows" I mean it's right there in the logs as 6.0.0.

[qntm]

Why do flake8 and black disagree about where line breaks should be relative to binary operators? Since they are in conflict, why are we using both of them at once? Shouldn't we just use one or the other?

[rwe]

Why do flake8 and black disagree about where line breaks should be relative to binary operators?

There are two things here:

• Line breaks relative to binary operators: they don't disagree, but flake8 has two mutually-exclusive rules (W503 and W504), and by enabling "all rules", one of them has to be suppressed. The one not suppressed is consistent with black and PEP8.
• Spacing around binary operators (e.g. in slices like x[i + 1 :]): flake8's warning (E203) is apparently also inconsistent with black and PEP8. I suppose "inconsistent" here means too aggressive: black does not want a space after the colon of open-ended slices.

Those two suppressions are described here: https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#configuration

Since they are in conflict, why are we using both of them at once? Shouldn't we just use one or the other?

black is an auto-formatter (in the vein of prettier) and flake8 is a linter (in the vein, maybe, of ~eslint) which includes rules about formatting. The formatting rules of flake8, which actually come from pycodestyle, are mostly redundant with black, but:

• At this point black is not integrated, so updating the formatting was mostly separable from a tooling change.
• Most of flake8's warnings are not formatting-related, and are still useful to keep: https://flake8.pycqa.org/en/latest/user/error-codes.html