4 ms·

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, an

• petters 7y ago
  From the experience in our code base, yapf produces higher-quality results, but is much slower. Black removes any additional parentheses added to enable a line split at a reasonable position (such as "and"). With those removed, black has to split at weird locations like at a function call. But switching to black just for the speed increase is reasonable.
  • smitty1e 7y ago
    My perfect formatter would be ridiculous to implement and maintain. Thus I "like" black's opinionated take. "I see some rude code and I want to paint it black, " -- Sir Mick Jagger, probably.
• lapink 7y ago
  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.
  • scrollaway 7y ago
    A somewhat-undocumented feature of black is that in recent versions, by giving the list a trailing comma, you're telling the indenter to always put it on multiple lines (eg `[1,2,]` will always wrap on 4 lines). If you remove the trailing comma to a multi-item list/dict/whatever, black will try to compact the literal to a single line (and if it fails because the line is too long, it will add the trailing comma back)
  • weberc2 7y ago
    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.
    • lunixbochs 7y ago
      I've seen Black do this (the dict needs to be too long to inline): call( { "key": "value", "key": "value", } )
      • guitarbill 7y ago
        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.
        • edflsafoiewq 7y ago
          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".
          • weberc2 7y ago
            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.