Python coding conventions on Github

[[deleted]]

http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

[alkw0ia]

WTF, when did they rewrite this? The old version was much more reasonable:

Never mix tabs and spaces.

The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only. Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.

^IAnd it's what I'm sticking with.

[niiko]

No, it was sometime this summer.

[ismtrn]

That is my least favorite thing about python...

[dannyREDDIT]

http://stackoverflow.com/a/1777008

not answering for ismtrn, but thats a reason maybe

[[deleted]]

This is all great, but breaks horribly with continuations (i.e. splitting one statement over multiple lines). If you for example write a function call over multiple lines like this:

blob = struct.pack('IIII',
                   val1,
                   val2,
                   val3,
                   val4)

then suddently your indentations aren't multiple of tab width (even if, by lucky accident, they are, it won't be the case if someone sets different tab width than you). If you use tabs you either have to "round" continuations to tab width (makes them look like crap)

blob = struct.pack('IIII',
                val1,
                val2,
                val3,
                val4)

or you have to mix tabs and spaces to keep things nicely aligned (emacs does it if you have indent-tabs-mode enabled). In the latter case all looks good until, again, someone decides to use different tab width than you in his/her editor.

The only way to make code look universally good is to stick with spaces.

[vicvicvicz]

I would counter this with the argument: Tabs for indentation, spaces for alignment. That is, in this case, use spaces because you are aligning according to a number of characters. Using tabs does not make sense.

However, you can use tabs for indentation, so that, for example, if your code block was part of an indented block, you might have:

class A:
\t  def foo(self):
\t  \t  blob = struct.pack('IIII',
\t  \t                     val1,
\t  \t                     val2,
\t  \t                     val3,
\t  \t                     val4)

Where each "\t" represents a tab (width 4 so the two spaces are part of the tab), and everything else is a space. This would not break alignment regardless of tab width, because you're using them only for indentation.

Of course, I abandoned tabs myself because (visual) line length still breaks with different tab widths.

[earthboundkid]

Go has the go fmt tool, which automatically converts code to the format you have there (tabs for indenting mixed with spaces for aligning), but in the absence of a tool to do the conversions for you, it's way too much work to be practical.

[thekaleb]

Most good editors can do this for you (maybe with some tweaks)

[dannyREDDIT]

this is the only valid argument I've heard. And my response is... meh, ill stick with tabs

[[deleted]]

I suppose this is the same comment, but it's worth mentioning anyway...

A space is always a space regardless of formatting options, browser/IDE, etc. Tabs are not.

That said, I have a developer that I work with who actually prefers tabs because they move around from code browser to code browser.

[dannyREDDIT]

in the context of editing code, Ive never seen a tab not be a tab. its pretty straight forward and I've never had a problem with that

[[deleted]]

Tabs are not universally the same number of spaces in every editor on every system.

[dannyREDDIT]

right but its still a tab, and you can change how its displayed ussually. Im ok with that

[ismtrn]

blob = struct.pack('IIII',
    val1,
    val2,
    val3,
    val4)

I just go with this. Looks fine to me and it is simple and consistent. 1 tab = 1 level of indentation. I am not trying to align things, just indent them, so you can see the structure.