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

51–60 of 67 posts

Re: Format Python Code Using YAPF

#51

Post by tzs »

Some editors or IDEs have pretty good automatic "formatting as you type" systems that can largely remove the need for stand-alone formatters for new code.

Sometimes you can convince them to processes an existing file as if it is being typed in and so apply the "as you type" formatter, effectively giving you a stand-alone formatter.

I used to do this with Emacs for C formatting. I don't remember how since I'm a vim user who only figured out enough Emacs for this one thing, and it was a long time ago, but I remember it worked very well. The Emacs C "as you type" formatter was very configurable and I was able to make it almost perfectly match my employer's style.

How's Emacs "as you type" Python formatting?

Re: Format Python Code Using YAPF

#52

Post by j88439h84 »

patrec wrote: post #32
scrollaway wrote: post #12

Earlier quoted context omitted.

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.

How to set an editor to use big visual indents for spaces?

Re: Format Python Code Using YAPF

#53

Post by no_wizard »

We used YAPF[0] before we used Black[1]

I really liked it, a lot. What set Black above is it is most of the decisions (if not all, really) makes is how we setup YAPF anyway. I do think it does some small things better, like reformatting function arguments in certain cases (as is highlighted elsewhere in this thread)

If you need configurability, YAPF is the best choice, in my opinion. We still use isort though, because it sorts imports in a much more readable way.

I just wish I could find a suitable replacement for C# development. StyleCop is okay, but I find we have to use `` .csproj settings on so many little rules and it doesn't auto format (in as so far as I can tell). If your editor supports it, it will use it as a formatting source of truth, though. I just want something that also has a runnable console binary we can use in CI. Maybe I haven't looked at it closely enough.

[0]https://github.com/google/yapf

[1]https://black.readthedocs.io/en/stable/

Re: Format Python Code Using YAPF

#54

Post by dbcurtis »

xapata wrote: post #47
00ajcr wrote: post #36

Earlier quoted context omitted.

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.

Yes, this. I have early-stage cateracs, which by-and-latge is not an issue on my 40 inch monitor. But it does mean that my astigmatism drifts around monthly. My prescription changes faster than I can get new lenses cut. The BIGGEST ergonomic issue for my with Python is single versus double quotes. Double quotes are the difference between happily coding all day versus a headache at lunch time and 5% less done. Fuck Black.

Re: Format Python Code Using YAPF

#55

Post by guitarbill »

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

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

  if error:
      msg = (
        "Lorem ipsum dolor sit amet, consectetur adipiscing elit. "
        "Maecenas vel ligula nec eros finibus metus."
      )
      raise ValueError(msg)
just to be clear, i don't think working around a formatter is good. in this case, i feel like the uncompromising rules were exposing a bit of an anti-pattern. obviously, your opinion on this may vary wildly.

Re: Format Python Code Using YAPF

#56

Post by zelly »

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…

While I prefer tabs whenever I can, I can see why it doesn't support it. If you have to share code, you're going to use spaces. For some reason everyone including Guido insists on spaces. I would rather not have to waste time thinking about formatting or much less which formatting style to use. New languages like Go and Rust solved this problem.

Re: Format Python Code Using YAPF

#57

Post by ScoutOrgo »

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

My team has a handful of junior data scientists that really don't have a lot of experience of coding "well". Black was super helpful in 1, getting people used to decent coding format and 2, removing any effort or discussion around formatting in PRs. I added the formatting to pre-commit and the rest is effortless.

Re: Format Python Code Using YAPF

#58

Post by brainbag »

dbcurtis wrote: post #54
xapata wrote: post #47

Earlier quoted context omitted.

But I want them normalized. Normalized to single quotes.

Yes, this. I have early-stage cateracs, which by-and-latge is not an issue on my 40 inch monitor. But it does mean that my astigmatism drifts around monthly. My prescription changes faster than I can get new lenses cut. The BIGGEST ergonomic issue for my with Python is single versus double quotes. Double quotes are the difference between happily coding all day versus a headache at lunch time and 5% less done. Fuck Bl…

Can you say more about how single quotes vs double quotes is helpful for you? I rarely write python, but I have a passion for accessibility and I'm curious about this.

Re: Format Python Code Using YAPF

#59

Post by patrec »

j88439h84 wrote: post #52
patrec wrote: post #32

Earlier quoted context omitted.

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.

How to set an editor to use big visual indents for spaces?

Depends on the editor, of course, but e.g.

https://www.emacswiki.org/emacs/redshift-indent.el

(Haven't tried the above, but I've done fairly extensive display hacks with emacs in the distant past, so I have a fair amount of confidence that it's not hard).

Re: Format Python Code Using YAPF

#60

Post by edflsafoiewq »

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…

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".
Post reply on HN