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

31–40 of 67 posts

Re: Format Python Code Using YAPF

#31

Post by scrollaway »

stubish wrote: post #16
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…

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.

Re: Format Python Code Using YAPF

#32

Post by patrec »

scrollaway wrote: post #12
jakear wrote: post #11

Earlier quoted context omitted.

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 ).

This argument sounds quite bizarre to me. Why would a visually impaired programer not manage to set their editor up to show indenting spaces the way they want, or failing that, collaborate with others to do so?

It's not like they can be effective at their job either without the ability to read 3rd party code, which overwhelmingly will be space indented.

Re: Format Python Code Using YAPF

#33

Post by cerberusss »

danpalmer wrote: post #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 revie…

> and so we've had many discussions internally about whether it's right for us

Many discussions? I've never been on a project where code style required anything more than 10 minutes. The tech lead would ask: "everybody okay with the defaults of this linter/editor/whatever" and we'd reply "sure".

How much time did those many discussions take, and what were the reasons you needed to put in that effort?

Re: Format Python Code Using YAPF

#34

Post by ForHackernews »

4140tm wrote: post #26
danpalmer wrote: post #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 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.

I hate black so much. I know it's somewhat irrational, but it's incredibly ugly and violates established usage in most Python projects.

Re: Format Python Code Using YAPF

#35

Post by akvadrako »

jp_sc wrote: post #30
akvadrako wrote: post #27

Earlier quoted context omitted.

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.

Where do you see that?

https://black.readthedocs.io/en/stable/the_black_code_style....

Re: Format Python Code Using YAPF

#36

Post by 00ajcr »

akvadrako wrote: post #35
jp_sc wrote: post #30

Earlier quoted context omitted.

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

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".

Re: Format Python Code Using YAPF

#37

Post by whitehouse3 »

jsmeaton wrote: post #24
danpalmer wrote: post #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 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.

Opening an issue on Black for anything but a true bug is chasing after the wind.

Re: Format Python Code Using YAPF

#38

Post by weberc2 »

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.

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.

Re: Format Python Code Using YAPF

#39

Post by weberc2 »

danpalmer wrote: post #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 revie…

This is a strange comment. It sounds like you’re using black wrong. First of all, when you pick Black, you throw away your own style guide (at least where black is concerned; keep the bits about function naming, etc). Secondly, you should only have one noisy commit, that being the very first commit in which you integrate Black. Thereafter, Black runs before code is committed so all code in code review is already formatted. Yes, if you already have comprehensive style linters and a team that agrees on style, you won’t see as much benefit, but you won’t need to maintain your custom linters or style guide or have all of these conversations about style (you also don’t need to iterate with a linter).

Re: Format Python Code Using YAPF

#40

Post by weberc2 »

ForHackernews wrote: post #34
4140tm wrote: 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.

I hate black so much. I know it's somewhat irrational, but it's incredibly ugly and violates established usage in most Python projects.

Any formatter will violate established usage in most Python projects. I find black at least makes your code readable, compared with pprint-esque styles.
Post reply on HN