Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Format Python Code Using YAPF

leimao.github.io

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Format Python Code Using YAPF

#11

Post by jakear »

scrollaway wrote: post #8
zelly wrote: post #2

I thought the community standardized on black

Black is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses. I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in py…

Thats a shame, especially as I've heard tabs are more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

Re: Format Python Code Using YAPF

#12

Post by scrollaway »

jakear wrote: post #11
scrollaway wrote: post #8

Earlier quoted context omitted.

Black is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses. I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in py…

Thats a shame, especially as I've heard tabs are more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

Precisely why I use them and why I'm uncomfortable with Black refusing to add the option (https://github.com/psf/black/pull/513).

Re: Format Python Code Using YAPF

#13

Post by scrollaway »

lapink wrote: post #10
fermigier wrote: post #3

I've used Yapf for a year, then switched to Black when it appeared. Seriously, use Black. I my experience, and to my taste, it works perfectly all the time, and the result is beautiful. It's also pep8 compliant, for the parts of pep8 that are concerned by a reformatter.

Black produces code with more lines than yapf. Sure sometimes yapf makes very weird decision (especially when using a dictionary litteral as an argument to a function) but at least it does not use 4 lines for a list with 2 items that could have fitted on one line.

A somewhat-undocumented feature of black is that in recent versions, by giving the list a trailing comma, you're telling the indenter to always put it on multiple lines (eg `[1,2,]` will always wrap on 4 lines). If you remove the trailing comma to a multi-item list/dict/whatever, black will try to compact the literal to a single line (and if it fails because the line is too long, it will add the trailing comma back)

Re: Format Python Code Using YAPF

#14

Post by gimboland »

bonzini wrote: post #5
duckerude wrote: post #4

Earlier quoted context omitted.

black is opinionated. If you disagree with black's opinions then a negotiable formatter like YAPF might be better. I personally love black though.

Black is opinionated enough that you will occasionally mumble about it, but good enough that you will keep using it anyway. That's a remarkable achievement for a formatter. For me it just took a little to get used to double-quoted strings. Rust's "cargo fmt" tool is similarly good.

I hear you on the double-quoted strings; and that's why the only black configuration I allow myself, is "skip-string-normalization = true" in my pyproject.toml

Re: Format Python Code Using YAPF

#15

Post by strokirk »

bonzini wrote: post #5
duckerude wrote: post #4

Earlier quoted context omitted.

black is opinionated. If you disagree with black's opinions then a negotiable formatter like YAPF might be better. I personally love black though.

Black is opinionated enough that you will occasionally mumble about it, but good enough that you will keep using it anyway. That's a remarkable achievement for a formatter. For me it just took a little to get used to double-quoted strings. Rust's "cargo fmt" tool is similarly good.

I'd say that black is way too opinionated, especially since it doesn't produce good output a lot of the time. At my company we consistently have to adjust the way we write code in order for black not to mangle it.

Re: Format Python Code Using YAPF

#16

Post by stubish »

scrollaway wrote: post #8
zelly wrote: post #2

I thought the community standardized on black

Black is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses. I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in py…

The reason Black is fast becoming standard is precisely because it is so opinionated. Like the other code formatters that have successfully become 'normal', such as gofmt. An option means that there isn't a standard, but several standards. And the people pushing Black in their projects see the benefit of a global standard, even though it is rarely 100% their personal preferences. It is a consensus.

Re: Format Python Code Using YAPF

#17

Post by mintplant »

zelly wrote: post #2

I thought the community standardized on black

I disagree with a few of Black's decisions, so I forked it to Lavender [0], which I keep up to date with the latest stable Black release (and use actively in all my Python projects).

> Differences from Black

> - The default line length is 99 instead of 88 (configurable with --line-length).

> - Single quoted strings are preferred (configurable with --string-normalization none/single/double).

> - Empty lines between classes and defs are treated no differently from other code. The old behavior, which sometimes inserts double empty lines between them, remains available via --special-case-def-empty-lines.

> - The Vim plugin configuration variable for line length is named g:lavender_line_length instead of g:lavender_linelength, for consistency with the other configuration variable names.

[0] https://github.com/spinda/lavender

Re: Format Python Code Using YAPF

#18

Post by hashhar »

The only successful formatter are ones who don't have any knobs to tune. The reason a formatter exists is to make all codebases look consistent, not to cater to your personal style.

This is one area Golang got it right with gofmt.

Re: Format Python Code Using YAPF

#19

Post by Lutzb »

hashhar wrote: post #18

The only successful formatter are ones who don't have any knobs to tune. The reason a formatter exists is to make all codebases look consistent, not to cater to your personal style. This is one area Golang got it right with gofmt.

This is the reason we switched to black for Python about a year ago. There are no options to tweak. At first I had to deal with a lot of complaining developers, but now everyone got accustomed to blacks formatting style and we moved on.

Re: Format Python Code Using YAPF

#20

Post by smitty1e »

petters wrote: post #9
fermigier wrote: post #3

I've used Yapf for a year, then switched to Black when it appeared. Seriously, use Black. I my experience, and to my taste, it works perfectly all the time, and the result is beautiful. It's also pep8 compliant, for the parts of pep8 that are concerned by a reformatter.

From the experience in our code base, yapf produces higher-quality results, but is much slower. Black removes any additional parentheses added to enable a line split at a reasonable position (such as "and"). With those removed, black has to split at weird locations like at a function call. But switching to black just for the speed increase is reasonable.

My perfect formatter would be ridiculous to implement and maintain.

Thus I "like" black's opinionated take.

"I see some rude code and I want to paint it black, " -- Sir Mick Jagger, probably.

Post reply on HN