Unexpected space after keyword argument

[DRMacIver]

yapf --style=pep8 formats the following code:

class ConjectureRunner(object):

    def _(
        self, test_function, settings=None,
    ):
        self.settings = ConjectureData(
            draw_bytes=lambda data, n, distribution:
            distribution(self.random, n)
        )

as the following output:

class ConjectureRunner(object):
    def _(
            self,
            test_function,
            settings=None, ):
        self.settings = ConjectureData(
            draw_bytes=
            lambda data, n, distribution: distribution(self.random, n))

The space after "settings=None," seems to be incorrect according to pep8 (both my interpretation of it and the pycodestyle checker's claim).

I've verified this both with yapf 0.16.1 and the current version in da3697c012016665b9fc537ce694bbc5bc7101dd

[bwendling]

Does the same hold true for a function call?

bork(test_function, settings,)

[lcary]

I think this is the same issue my team is seeing with flake8 failures when people have auto-formatted code with yapf. Specifically, yapf adds a newline (and indentation) after the equals sign for kwargs, causing error code 251.

Python script before yapf, for which flake8 shows no error:

x = dict(
    key='loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string.')  # noqa: E501

Python script after running yapf --style=pep8:

x = dict(
    key=
    'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string.'
)  # noqa: E501

flake8 fails with:

$ flake8 yapf-issue-393.py
yapf-issue-393.py:2:9: E251 unexpected spaces around keyword / parameter equals
yapf-issue-393.py:3:80: E501 line too long (95 > 79 characters)

I'm not sure if having a newline after the equals sign is valid style by pep8 standards, so it's possible this is a bug with flake8/pycodestyle and not yapf.

[sk-]

We are seeing the same issue when trying to limit our codebase to 80 characters (so side by side PR comparison on Github are easier to read).

There's this open issue https://github.com/PyCQA/pycodestyle/issues/301 regarding this very situation.

[martinohansen]

This is still an issue for me, have anyone found a workaround?