I prefer not hitting tab at all because my editor already knows how far to indent. But when it does indent, I like it to use tab characters as a way to distinguish semantic indentation from alignment indentation.
And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc.
Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file.
Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces.
For example:
def foo():
--->if (long_named_function_that_returns_a_boolean() and
--->....thing2() and thing3()):
--->--->do_stuff()
And again, with your editor reconfigured to display tabs as two characters wide:
def foo():
->if (long_named_function_that_returns_a_boolean() and
->....thing2() and thing3()):
->->do_stuff()
Basically, tabs get you several niceties with partially-dumb editors like emacs or vim. Indenting with spaces gives that all up and all you get in return is the ability to view code with notepad.exe.
> Further, what if you prefer 2 or 3 space indentation?
This, alone, is why I always use tabs, no matter what any style guide says. People have different tastes. Using tabs allows any editor to indent according to personal tastes.
The only exception to that rule that I personally make is indenting in-line comments; I've found that some comment-heavy code benefits from alignment, but multiparagraph alignment is a futile and counterproductive goal, so the tab mark is a good fit.
Isn't it a little self-defeating to make indentation visible? The whole idea is that it's easy to pick out blocks by the shape of the left margin, i.e., where the first visible character is.
If your indentation scheme only works when configuring your editor to mark whitespace, we might as well go back to MUMPS and indent with dots.
And because emacs and vim are still "dumb" editors in some ways: They still conflate the arrow keys with "move one character", when they should really mean "move one character, unless you are in non-alignment indentation, in which case move one level of indentation, which happens to correspond to four spaces since this particular file is python." They have similar problems with backspace and delete, regexes and search/replace, etc.
Further, what if you prefer 2 or 3 space indentation? If you use semantic tabs, you can have that simply by changing the display width of the tab character. It needn't be equivalent in width to 8 characters. To my knowledge, emacs and vim are both too dumb to display code indented with spaces at a different indentation width than saved in the file.
Note that when using semantic tabs, tabs only represent semantic indentation. A new block adds a tab. Further indentation for the purpose of aligning multi-line statements must be done with spaces. Tabs following spaces on a line are always wrong. Tabs are not to be used to align to columns. If you want to do that, use spaces.
For example:
And again, with your editor reconfigured to display tabs as two characters wide: Basically, tabs get you several niceties with partially-dumb editors like emacs or vim. Indenting with spaces gives that all up and all you get in return is the ability to view code with notepad.exe.