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

41–50 of 67 posts

Re: Format Python Code Using YAPF

#41

Post by weberc2 »

scrollaway wrote: post #31
stubish wrote: post #16

Earlier quoted context omitted.

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.

Prettier is more widespread than black, is very opinionated, and still has an option for tab indent. This is a strawman.

How is this argument a strawman?

Re: Format Python Code Using YAPF

#42

Post by closed »

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.

> The reason a formatter exists is to make all codebases look consistent

I'm not how this is related to not having any knobs to tune. Aren't there many ways for code to be consistent with pep8? Isn't advocating for only one version of pep8-consistent code in essence an attempt to supercede pep8?

Re: Format Python Code Using YAPF

#43

Post by weberc2 »

aequitas wrote: post #7
zelly wrote: post #2

I thought the community standardized on black

It doesn't really matter which standard you use imho, as long as you automate the tedious task of code formatting to arbitrary standards. If it's something the computer can do let it do it don't waste your time on it. This goes especially in pull requests where dedicated focus to trivial things like formatting often distracts from the real things that need review, like code architecture.

It would be nice if things converted on a single standard, however.

Re: Format Python Code Using YAPF

#44

Post by aequitas »

weberc2 wrote: post #43
aequitas wrote: post #7

Earlier quoted context omitted.

It doesn't really matter which standard you use imho, as long as you automate the tedious task of code formatting to arbitrary standards. If it's something the computer can do let it do it don't waste your time on it. This goes especially in pull requests where dedicated focus to trivial things like formatting often distracts from the real things that need review, like code architecture.

It would be nice if things converted on a single standard, however.

True, but the order of things will never allow this to happen, either the old standard lags behind, some people disagree on something (just look at the tabs vs spaces discussion) or some people just have inherently different personal preferences. Then there is always the eb and flow of of convergence and deviation. Thats why I've given up on pushing my preferred standard in a team and just enforce the rule that is must be automated so I don't have to spend time on it no matter which way the current standard wind blows.

Re: Format Python Code Using YAPF

#45

Post by dewey »

closed wrote: post #42
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.

> The reason a formatter exists is to make all codebases look consistent I'm not how this is related to not having any knobs to tune. Aren't there many ways for code to be consistent with pep8? Isn't advocating for only one version of pep8-consistent code in essence an attempt to supercede pep8?

They are most likely talking about the codebase being consistent within a company / project. Not consistent with pep8.

If there are no knobs to turn (like in gofmt) everyone just has the same settings and you don't have to make sure everyone sets the knobs to the same values.

Re: Format Python Code Using YAPF

#46

Post by lunixbochs »

weberc2 wrote: post #38
lapink wrote: post #10

Earlier quoted context omitted.

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.

I’m pretty sure Black doesn’t do that, it will fit them onto a single line if possible, then it will move the kv pairs onto their own line, and failing that, one kv pair per line. In any case, I’m fine with more lines. Clarity is much more important than minimizing line count.

I've seen Black do this (the dict needs to be too long to inline):

  call(
      {
          "key": "value",
          "key": "value",
      }
  )

Re: Format Python Code Using YAPF

#47

Post by xapata »

00ajcr wrote: post #36
akvadrako wrote: post #35

Earlier quoted context omitted.

Where do you see that? https://black.readthedocs.io/en/stable/the_black_code_style....

I think it's the `--skip-string-normalization` flag which means "Don't normalize string quotes or prefixes".

But I want them normalized. Normalized to single quotes.

Re: Format Python Code Using YAPF

#48

Post by kstrauser »

Lutzb wrote: post #19
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.

Same. It looked weird at first, and everyone had specific complaints with it, but they were all different complaints. Now we all accept that it’s just what Python code looks like, and can stop thinking about it all.

Re: Format Python Code Using YAPF

#49

Post by zzzeek »

londt8 wrote: post #21
Lutzb wrote: post #19

Earlier quoted context omitted.

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.

That is one of the few things you can set, put it in your pyproject.toml, done.

Oh you don't have a pyproject.toml? Well then we have a different problem :)

Re: Format Python Code Using YAPF

#50

Post by zzzeek »

closed wrote: post #42
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.

> The reason a formatter exists is to make all codebases look consistent I'm not how this is related to not having any knobs to tune. Aren't there many ways for code to be consistent with pep8? Isn't advocating for only one version of pep8-consistent code in essence an attempt to supercede pep8?

Black formats to a subset of pep8 so I guess it's an attempt to "subcede" pep8.
Post reply on HN