Live data from Hacker News

Format Python Code Using YAPF

leimao.github.io

21–30 of 67 posts

Re: Format Python Code Using YAPF

#21
post #19
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.

It has questionable default of 88 characters per line, which is configurable. I wish they chose 79 characters as PEP8 suggests.

Re: Format Python Code Using YAPF

#22
A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure.

Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make review easier. One of the primary ways of doing this is minimising diff noise.

While Black's vision is to reduce diff noise and design for easier review through a consistent style, it creates more diff noise and has a less consistent style than our style guide, and so we've had many discussions internally about whether it's right for us.

I have no doubt that Black is better than weak/no style guide, and for open source projects the automation it brings would absolutely be the right choice. I just wish it was better at what it sets out to do.

Edit: to address some of the questions raised:

- Yes Black does save time over code review picking on style details, but we already have automated linters for most things we'd raise about style anyway, which negates some of the time saving.

- The easiest example of where Black differs from our style guide and falls down on its promises is formatting lists/function calls/definitions.

For example:

  foo = [bar, bar]
When reaching the line length limit, we will turn this into:

  foo = [
    bar,
    baz,
    quux,
  ]
However Black will format this first as:

  foo = [
    bar, baz, quux
  ]
Only when it goes on a few more characters does it then format into the way we'd go straight to. This means that there's more diff noise more of the time, and when reading code there are 3 forms of this construction that one must be aware of, rather than the 2 forms that we have, meaning the code is less consistently formatted.

This is picky, yes, but the point of Black is to be picky, and in a team where we can have a very good shared understanding of a style, and where we do already have that style, Black is much less convincing.

Re: Format Python Code Using YAPF

#23
I dislike a lot of black decisions and still use it for everything.

My aesthetic taste is less important than getting things done.

If you are not using it, stop arguing and nit picking about your preferences, we, as a community, have more important things to do. It will hurt only a little, I promise.

Re: Format Python Code Using YAPF

#24

A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make revie…

Have you got any specific examples of different rules/styles? Have you brought any of them up on the issue tracker?

I’m a very big fan of black, and had disliked a few choices. But it’s saved our team literally dozens of hours of nit picking and style fixes. It’s so good to never have to critique style and just focus on function.

Re: Format Python Code Using YAPF

#25

A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make revie…

How, specifically, do you minimise diff noise? I can imagine a couple of ways:

- Split to as many lines as possible in order to avoid suddenly going from one line to many lines and vice versa when a line crosses a specified line length

- Add trailing commas wherever possible

Re: Format Python Code Using YAPF

#26

A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make revie…

I have hated every single formatter I've tried, other than Black. It seems to be the only one that's not just trying to put style into PEP8 compliance, but also keep it readable and maintainable.

I'm also curious about the issues you've had with it.

Re: Format Python Code Using YAPF

#27
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 cl…

Nice to hear. The single quote issue is the main thing that keeps me from using black. Double quotes are just too noisy.

Re: Format Python Code Using YAPF

#28
post #26

A bad formatter is worse than no formatter, and unfortunately YAPF proves this out in my experience, being unstable, inconsistent, and tricky to configure. Black however could fall into this category of worse than no formatter. On my team we have a strong style guide with a lot of well-reasoned, detailed, and consistent rules. One of the main differences to other style guides is that we design our style to make revie…

I have hated every single formatter I've tried, other than Black. It seems to be the only one that's not just trying to put style into PEP8 compliance, but also keep it readable and maintainable. I'm also curious about the issues you've had with it.

The outout of Black is PEP8 compliant, just not what flake8 think PEP8 mandates.

Re: Format Python Code Using YAPF

#29
post #28
post #26

Earlier quoted context omitted.

I have hated every single formatter I've tried, other than Black. It seems to be the only one that's not just trying to put style into PEP8 compliance, but also keep it readable and maintainable. I'm also curious about the issues you've had with it.

The outout of Black is PEP8 compliant, just not what flake8 think PEP8 mandates.

Weird. I also use flake8 and the only mismatch between the two has been the default line length of black, which I changed to 79. All is good now.

Re: Format Python Code Using YAPF

#30

Earlier quoted context omitted.

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 cl…

Nice to hear. The single quote issue is the main thing that keeps me from using black. Double quotes are just too noisy.

Black can be configured to use single quotes. In fact, I think it's the only style configuration you can make.
Post reply on HN