[msutherl]

The tabs vs. spaces debate makes me very sad. I get it, big companies use spaces because interns are stupid and don't understand how tabs work. And some people monomaniacally want their code to look exactly the same everywhere.

But I wish it could just be acknowledged somewhere that, if you know what you're doing, tabs are better and have no downsides (except that you can't control how other people see your code).

Caveat: I really mean tabs + spaces for complicated formatting beyond the indent level of the current line.

Regarding 80 character width, I'm often coding on my laptop and I really appreciate it when code is kept within those bounds as it allows me to vertically tile 3 files without line-breaks. Also, I find that it forces me to write more succinctly. 'One idea per line' is a good idea and 80 characters is a good arbitrary limitation that helps me achieve that.

[pavel_lishin]

I'm a convert to spaces after someone pointed out that it's easier to make your code 'pretty'.

    // This doesn't look very nice
    thing = { some_key_1: some_var_1,
    [->][->][->]some_key_2: some_var_2,
    [->][->][->]some_key_3: some_var_3 }
    
    // Neither does this.
    thing = { some_key_1: some_var_1,
    [->][->]some_key_2: some_var_2,
    [->][->]some_key_3: some_var_3 }
    
    // Feels good, man.
    thing = { some_key_1: some_var_1,
              some_key_2: some_var_2,
              some_key_3: some_var_3 }
    
    // I want to beat you with an oar.
    thing = { some_key_1: some_var_1,
    [->][->]  some_key_2: some_var_2,
    [->][->]  some_key_3: some_var_3 }

[JensenDied]

Use tabs to align stuff on the left. This means putting some_key_1 on the next line. Also move the closing brace to a new line and add a comma after some_var_3.

Added advantage that you can move all of the lines around, :sort them or comment out individual ones without breaking anything.

Use spaces to align anything after the key, I usually align them with a tab stop so that several blocks line up.

  thing = {
  [->]some_key_1: some_var_1,
  [->]some_key_2: some_var_2,
  [->]some_key_3: some_var_3,
  }

[amcgregor]

I use an alternate form that doesn't require alignment to an arbitrary column and works with tab indentation without needing to mix:

  thing = {
  [→][→]some_key_1: some_var_1,
  [→][→]some_key_2: some_var_2,
  [→][→]some_key_3: some_var_3,
  [→]}

Several benefits: easier to insert lines at the head or tail without making the SCM diff ugly, also avoids merge conflicts in those cases, and I use indentation of two levels to separate it from code.

Why suffer a problem when it's easily avoided? :)

[DanBC]

Watch out or you'll get

    // I want to beat you with an oar.
    thing = {[->]some_key_1: some_var_1,
    [->][->][- >]some_key_2: some_var_2,
    [->][->][- >]some_key_3: some_var_3 }

[TallGuyShort]

Another tabs-only approach is to also add a single tab before some_key_1.

[mrkodiak]

When working on code bases that follow this style, there tends to be extra whitespace turn when new code is added to re-align everything back up.

[msutherl]

What's wrong with the "I want to beat you with an oar" approach? This is what I do and it works great.

[amcgregor]

Python is one-statement-per-line, which is already a pretty good limiter of line length. Just don't go crazy with ternary operators (which are hard to read anyway and thus against the Zen for more than the trivial cases) or literal definitions.

My FOSS libraries follow a 120-character wrapping limit and avoids alignment, but otherwise follows PEP-8. The main reason it was upped was the stupid arbitrary wrapping of lines that were only a few characters over the limit.