YAPF – A formatter for Python files

<p><pre><code> --style STYLE specify formatting style: either a style name (for example &quot;pep8&quot; or &quot;google&quot;), or the name of a file with style settings. pep8 is the default. </code></pre> &gt; pep8 is the default.<p>I can breathe again.

I&#x27;m sure there are some cases where this is useful, but I&#x27;m not really sold. The pitch at the beginning is &quot;satisfying PEP 8 doesn&#x27;t mean it looks good!&quot; 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.<p>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.<p>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&#x27;s?

&gt;YAPF is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.

I&#x27;ve been using YAPF for a while and I really like the idea. Be aware that there are still some nasty bugs that haven&#x27;t been fixed yet so be careful if you use it for something important.<p>Do anyone of you guys know what the name YAPF comes from? (The only thing I can think of is &quot;Yet Another Python Formatter&quot;, but I&#x27;m just guessing)

I&#x27;ve got a python project where I&#x27;ve been pretty naughty with long lines containing sql queries.<p>I found that running this tool over it resulted in some strange new lines.<p>For example, this was my old hideously long line:<p>query_qual = &quot;INSERT OR REPLACE INTO Qualifying (poleid, seasonid, race_week_num, carclassid, pole) values (%s%s, %s, %s, %s, %s)&quot; % (race[u&#x27;seasonid&#x27;], race[u&#x27;race_week_num&#x27;], race[u&#x27;seasonid&#x27;], race[u&#x27;race_week_num&#x27;], race[u&#x27;carclassid&#x27;], pole)<p>Changed to this:<p>query_qual = &quot;INSERT OR REPLACE INTO Qualifying (poleid, seasonid, race_week_num, carclassid, pole) values (%s%s, %s, %s, %s, %s)&quot; % ( race[u&#x27;seasonid&#x27;], race[u&#x27;race_week_num&#x27;], race[ u&#x27;seasonid&#x27; ], race[u&#x27;race_week_num&#x27;], race[u&#x27;carclassid&#x27;], pole)

Off-topic, but why is no space before opening parenthesis the norm in programming (&quot;class foo(object):&quot;) when normal English usage is to have one? I know myself as the only one who puts this space.

This passed HN duplicate detector, despite same URL and submission title.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9260786" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9260786</a>

Is it possible to YAPF it in Sublime?

There seems to be a problem parsing backslash escapes:<p>echo &#x27;foo=&quot;\\&quot;&#x27; | PYTHONPATH=&#x2F;tmp&#x2F;yapf&#x2F;yapf python &#x2F;tmp&#x2F;yapf<p>Raises a lib2to3.pgen2.parse.ParseError.<p>Also crashes on \n, but not, strangely, on \t.<p>I’m guessing that the backslashes get interpreted twice, somehow.

I definitely would like to see configuration options for the vertical alignment of arguments. If the arguments don&#x27;t fit within the line length then having the option to put them on separate lines (still pep8) would be nice.

&gt; YAPF is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.<p>Just in case anyone thought &quot;by Google&quot; meant &quot;a Google product&quot; like me.

Interesting to see the formatter is written using 2 space indentation when both pep8 and google&#x27;s style guides say 4.

i use autopep8 and haven&#x27;t been thrilled. it gets the job done, but i&#x27;ll switch in a heartbeat if this is better. we&#x27;ll see.

Also see go fmt