Indentation style...

[Tim Peters]

[Thomas Wouters]
> ...
> If you want to re-indent, your editor can re-indent the code in
> whatever way you wish, though I would vote against it. Or you can
> use Tim's lifework, 'tabnanny.py', to do it for you.

He actually wants reindent.py, which reindents, and nukes hard tabs, and
nukes trailing whitespace, and ensures the last line of the file ends with a
newline, all *assuming* tabnanny already gave the file a clean bill of
health.  tabnanny only detects ambiguous space/tab mixtures in leading
whitespace, making no assumption about "what a tab means" except that it
means *some* number of columns greater than 0.  It will detect ambiguity if
a hard tab means 1 space, or a million spaces.  If the only ambiguities
you're concerned about are between 4- and 8-space tabs, running the Python
compiler with -tt does the same thing more conveniently (but cannot detect
all ambiguities if tabs mean something other than 4 or 8).

> Personally, for Python code, I think 8 space indents (or single tab
> indents, if you prefer) are too big:

Since that's what Guido thinks too, it doesn't matter what we think <wink>.

> ...
> Why wouldn't comments be allowed to contain tabs ?

reindent.py nukes *all* hard tabs:  you won't find any hard tabs in the
Python Library.  The inability of people to agree about what a tab means
makes structured comments containing tabs unreadable across platforms.

> ...
> You generally want to outline them properly, and that's what tabs are
> for, after all.

Tabs interpreted as screen distance from the margin can mean that, but
"round up to a multiple of N columns" tabs are only useful provided everyone
agrees on a single value for N.  I expect tabs in that sense were really
introduced as a cheap-ass compression gimmick, back in the days when the
percentage of your disk space devoted to plain text files still fit in the
dynamic range of a 32-bit float <wink>.