[bkcooper]

I'm sure there are some cases where this is useful, but I'm not really sold. The pitch at the beginning is "satisfying PEP 8 doesn't mean it looks good!" But then it seems most of the changes cleaned up in the code (indentation level, indents on split lines, spacing between operators) are just PEP 8 violations. I think you could find a more convincing demonstration.

The warning about choking on large data literals (which are probably one of the places where prettifying would be most useful, at least to me) also seems ominous.

edit: for my personal use, I tend to use flycheck with flake8 in emacs. This keeps me honest. Is the primary use case for something like this cleaning your own code or other people's?

[eliben]

yapf starts making tons of sense after you've used similar tools in other languages. The chief two examples are "go fmt" and clang-format. The former goes without saying - formatting is enforced in Go.

The latter is widely used to format C, C++ (and even JS and Java) code. Many projects these days require all code to be clang-format'ed and even enforce it in commit hooks and such.

After working on such projects for a while, you get so used to the convenience of an auto-formatting tool, that you want it in all languages you code in. It's extremely useful to be able to just type a bunch of code quickly into the editor, copy-pasting, renaming, and know that the tool will nicely format it for you. Another advantage is that the whole code in a projects starts being and looking very consistent, which is important. Holy wars about brace placement and indentation just disappear.

So yapf is essentially that, for Python.

[wting]

FWIW, at Yelp we built and open sourced pre-commit (http://pre-commit.com/) that runs a bunch of hooks on git commits. One of the most commonly used hooks is `autopep8 -i` which will automatically formats code on commit.

As yapf documentation has pointed out, pep8 is vague about certain things (i.e. indention). Yelp prefers an indention style where multiple arguments are broken up 1 per line and has a pre-commit hook to automatically enforce that. yapf is also opinionated about indentation, preferring vertical alignment. I've run it on an open source project to illustrated the differences (YelpDent vs yapf indent):

     def remove_user_data(dryrun=False):
         if platform.system() == 'Darwin':
    -        data_home = os.path.join(
    -            os.path.expanduser('~'),
    -            'Library',
    -            'autojump')
    +        data_home = os.path.join(os.path.expanduser('~'), 'Library',
    +                                 'autojump')
        elif platform.system() == 'Windows':
            data_home = os.path.join(os.getenv('APPDATA'), 'autojump')
        else:
    -        data_home = os.getenv(
    -            'XDG_DATA_HOME',
    -            os.path.join(
    -                os.path.expanduser('~'),
    -                '.local',
    -                'share',
    -                'autojump'))
    +        data_home = os.getenv('XDG_DATA_HOME',
    +                              os.path.join(os.path.expanduser('~'), '.local',
    +                                           'share', 'autojump'))

[eliben]

We're actually working on a heuristic that can signal yapf to break arguments to one per line, and do the same for data structures (think a dict initialization).

Ultimately, we'd like to have these things configurable via the style settings of yapf, so multiple detailed styles can be selected.

Patches welcome :)

[zo1]

If you'd like my suggestion. I've been quite annoyed with some of the "odd" or "non-consistent" ways for splitting long lines onto multiple lines (either on definitions, or plain calls to functions). Eventually, I did come up with a consistent way to do so. Have a look at below:

    def OtherLongFunctionName(One,
      Two,
      Three
    ):
        print "Does stuff"
    
    def MyFunction(Param1,
      OtherParam,
      FooParam,
      EtcParam
    ):
        if ((Param1 * 1000) > 5000 &&
          OtherParam is not None &&
          len(FooParam) > 50
        ):
            new_instance_dict = {
              "TestingFoo": Param1,
              "NewFoo": OtherParam,
              "LongFooBar": FooParam,
            }
    
        recursive = MyFunction(
          OtherLongFunctionName(
            Param1,
            OtherParam,
            FooParam
          )
        )

It doesn't comply to PEP8 due to the indentation of nested params and stuff on the new lines. PEP8 apparently wants them aligned with the opening/starting bracket. This looks horrible, and just right-aligns all your code into little columns. And doesn't work very well with nested function calls.

[data_scientist]

Please don't make it configurable, because it will mean there is no longer "a" YAPF standard. Also look at Pycharm reformat tool, it would be a shame if both couldn't be used in the same versionned project.

[bpicolo]

The point is there are things that don't violate pep8 that are still atrocious

for example:

    some_function(long_variable_name_and_stuff, long_variable_name_and_stuff,
                                  long_variable_name_and_stuff)

The lower indentation level doesnt actually matter at all says flake8

edit: To below, that's possible. I can't remember the exact case right now but there are things along these lines that are valid and shouldn't be. Multiple possible indentation formats is not necessarily something you want to allow as an org, which is where something like YAPF comes into play

[bkcooper]

I wonder if that's a configuration thing. Mine gives me a "continuation line over-indented for visual indent" here.

[pekk]

I'm afraid you are mistaken here. PEP 8 reads "Arguments on first line forbidden when not using vertical alignment." flake8 does report this, but if it did not, that would simply be a bug in flake8.

edit: if there are bugs in PEP 8, work to get them fixed rather than promoting alternative styles like the Google style, please!

[morbo_yapf]

The warning about data literals is just to warn people that what comes out of YAPF may not look like they desire. The problem is that formatting data literals is hard. Even harder than formatting executable code. This is because there are so many different styles that could be applied to them. There's no "one size fits all" solution.

Therefore, YAPF (and even clang-format) balk on them. They will handle them of course. But the result will almost certainly not look like what you want.

That's why we give you the ability to disable formatting for sections of code.

[ngoldbaum]

I do this too but I really don't like the noticeable lag that gets introduced as flycheck shells out to python and parses my file every time I change something.

[klibertp]

Are you sure the lag is because of Python? I'd check flymake options first, it may wait for some time after you stop typing and only then start linting. This delay is a trade-off: too short and you're going to have currently edited line marked with red most of the time, too long and you need to wait to see if everything is alright.

[ngoldbaum]

Lazy HN for the win! Thanks for the suggestion.