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

61–67 of 67 posts

Re: Format Python Code Using YAPF

#61

Post by weberc2 »

lunixbochs wrote: post #46
weberc2 wrote: post #38

Earlier quoted context omitted.

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", } )

Right, but the parent claims it will do that when it would fit on a single line, unless I misunderstood something.

Re: Format Python Code Using YAPF

#62

Post by weberc2 »

guitarbill wrote: post #55
lunixbochs wrote: post #46

Earlier quoted context omitted.

I've seen Black do this (the dict needs to be too long to inline): call( { "key": "value", "key": "value", } )

yeah, can be annoying, but also encourages this, which is nice when the number of values grows: items = { "key": "value", "key": "value", } call(items) it's a bit annoying with exception messages, but again, writing long args before works great, and i've become a fan of this (unintended?) nudge: if error: raise ValueError( "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas vel ligula nec eros finibus…

I’m honestly fine with putting the dict in the function call in most cases. It’s not a big deal either way. As for your exceptions, you can just do

    raise ValueError(
        "Lorem ipsum dolor sit amet, consectetur adipiscing elit. "
        "Maecenas vel ligula nec eros finibus metus."
    )
No need for the extra variable.

Re: Format Python Code Using YAPF

#63

Post by weberc2 »

edflsafoiewq wrote: post #60
guitarbill wrote: post #55

Earlier quoted context omitted.

yeah, can be annoying, but also encourages this, which is nice when the number of values grows: items = { "key": "value", "key": "value", } call(items) it's a bit annoying with exception messages, but again, writing long args before works great, and i've become a fan of this (unintended?) nudge: if error: raise ValueError( "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas vel ligula nec eros finibus…

This puts the lie to the common claim that formatters end formatting decisions. Actually they only move the problem from "how shall I format my code" to "how shall I write my code so that I will like the way my autoformatter formats my code".

You misunderstand the point of formatters. They aren’t meant to automate your personal preference; they automate a standard format so your team doesn’t have to waste time deciding on and enforcing a coding standard and so you don’t have to manually implement the standard. Implicit in using a code formatter is the decision to stop navel gazing and put the team first.

Re: Format Python Code Using YAPF

#64

Post by [deleted] »

weberc2 wrote: post #63
edflsafoiewq wrote: post #60

Earlier quoted context omitted.

This puts the lie to the common claim that formatters end formatting decisions. Actually they only move the problem from "how shall I format my code" to "how shall I write my code so that I will like the way my autoformatter formats my code".

You misunderstand the point of formatters. They aren’t meant to automate your personal preference; they automate a standard format so your team doesn’t have to waste time deciding on and enforcing a coding standard and so you don’t have to manually implement the standard. Implicit in using a code formatter is the decision to stop navel gazing and put the team first.

[deleted]

Re: Format Python Code Using YAPF

#65

Post by closed »

zzzeek wrote: post #50
closed wrote: post #42

Earlier quoted context omitted.

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

I think that thing X superceding thing Y is equivalent to thing Y subceding to thing X.

In this case, if black becomes the standard for defining appropriate style then it is superceding pep8 as the standard for style (many styles consistent with pep8 are not black outputs, so if black's style becomes mandatory, it is a ruling against these previously accepted alternatives).

Re: Format Python Code Using YAPF

#66

Post by stubish »

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.

Prettier's opinion then is that tabs are irrelevant to the formatting. Which is probably fine for the all the languages Prettier seems to support. Unlike Python, where tabs vs spaces matter. Mixing tabs and spaces is a problem, and a formatter cannot automatically support both or risks changing the meaning of code.

Re: Format Python Code Using YAPF

#67

Post by scrollaway »

stubish wrote: post #66
scrollaway wrote: post #31

Earlier quoted context omitted.

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

Prettier's opinion then is that tabs are irrelevant to the formatting. Which is probably fine for the all the languages Prettier seems to support. Unlike Python, where tabs vs spaces matter. Mixing tabs and spaces is a problem, and a formatter cannot automatically support both or risks changing the meaning of code.

I don't know how you arrive to this conclusion… prettier never mixes tabs and spaces, it would be a bug if it did. And there's no meaningful difference between tabs and spaces in Python either. Python has significant indent stops, that's all.

Furthermore, prettier has a python plugin which does support tabs.

Post reply on HN