34 ms·

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 th

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?

ngoldbaum 12y ago
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 12y ago
  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 12y ago
    Lazy HN for the win! Thanks for the suggestion.
bpicolo 12y ago
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 12y ago
  I wonder if that's a configuration thing. Mine gives me a "continuation line over-indented for visual indent" here.
- pekk 12y ago
  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!
eliben 12y ago
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 12y ago
  FWIW, at Yelp we built and open sourced pre-commit (http://pre-commit.com/ 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'))
morbo_yapf 12y ago
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 12y ago

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 12y ago
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 12y ago
  Lazy HN for the win! Thanks for the suggestion.

bpicolo 12y ago

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 12y ago
I wonder if that's a configuration thing. Mine gives me a "continuation line over-indented for visual indent" here.
pekk 12y ago
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!

eliben 12y ago

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 12y ago
FWIW, at Yelp we built and open sourced pre-commit (http://pre-commit.com/ 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'))

morbo_yapf 12y ago

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.