That’s exactly what we can use in the docs about incompatibilities!

Great job! Thanks a lot. 👍

I am not sure what does official support means here. Does this Makefile task used for linting this repo?

I can make PR if waiting couple of weeks is okay.

Also looks like black is now leaving trailing commas, if python36 support is enabled, if I understand objective in your doc correcly. Black doc says:

Black will add trailing commas to expressions that are split by comma where each element is on its own line. This includes function signatures.

Unnecessary trailing commas are removed if an expression fits in one line. ... That doesn’t make diffs any larger.

https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=flake8#trailing-commas

I would love to edit the text to reflect what the people have said regarding the attempt to make black compatible with WPS.

Also another note:

You could use the double-quote-string-fixer pre-commit hook.

See https://github.com/pre-commit/pre-commit-hooks

Done steps

If I understand correctly to add autopep8 analog in make lint, would be equivalent to adding black --check .. For this codebase must be formated with black first.

I tried to format codebase with configured black, and this leads to huge changes. Diff stat is: 303 files changed, 6739 insertions(+), 9085 deletions(-).

Then I check, if reformated codebase matches flake8 checks. Here is stats of found violations (that, as far as I understand, it’s worth considering incompatibilities):

Number of errors - Code
871 - C812: missing trailing comma
3   - C815: missing trailing comma in Python 3.5+
8   - C816: missing trailing comma in Python 3.6+
12  - D202: No blank lines allowed after function docstring
3   - E203: whitespace before ':'
34  - W503: line break before binary operator
6   - WPS221: Found line with high Jones Complexity: 17
36  - WPS317: Found incorrect multi-line parameters
2   - WPS348: Found a line that starts with a dot

Description of incompatibilities

C812 - appears in case when all arguments are on the same line, but brackets are on surrounding lines (checked 5 examples). Example of incompatible code, formatted with black:

def test_false_positives_are_ignored(
    code, assert_errors, parse_tokens, default_options
):

D202 appears only in case, when local function comes right after docstring (i checked about 5 examples of error). Example of incompatible code, formatted with black:

@pytest.fixture()
def positive_number_wrapper():
    """Fixture to return positive numbers with explicit ``+``."""

    def factory(template: str) -> str:
        return '+{0}'.format(template)

    return factory

E203 is known incompability betweeen flake8 and black. They claim that is issue on flake8 side: https://github.com/psf/black/issues/315#issuecomment-395457972

W503 is known incompability betweeen black and pycodestyle. Black claims that W503 is against PEP8. pycodestyle docs says that W503 is disabled by default, because “they are not rules unanimously accepted, and PEP 8 does not enforce them”. https://github.com/psf/black/issues/52

WPS317 in all, but one, cases is encountered in comples @pytest.mark.parametrize. Probably somehow related with multiline lists/tuples in arguments. Example formatted with black:

@pytest.mark.parametrize(
    ('args', 'statement'),
    [
        ('self', '""""""'),
        ('self', 'return 1'),
        ('self', 'return Useless.function()'),
        ('self', 'return Useless().function()'),
        ('self', 'return Useless()().function()'),
        ('this', 'return super().function()'),
    ],
)

WPS348 - looks like black has different strategy on such cases https://black.readthedocs.io/en/stable/the_black_code_style.html#call-chains

Yeap, official support in this context means that we check that all our code is compatible with the autoformatter we support. We guarantee it by adding this check inside the CI. And since we support python3.6+ we are also fine with the trailing comma feature.

Several weeks are totally fine, no pressure here.