Non-Indented python

Chris Liechti cliechti at
Thu Nov 22 02:02:15 CET 2001

"Delaney, Timothy" <tdelaney at> wrote in
news:mailman.1006384828.32275.python-list at 

>> From: Jeff Shannon [mailto:jeff at]
>> Dave Cinege wrote:
>> > Rule of God:
>> > The punishment for non-tab based indentation is death.
>> This is exactly backwards.
>> Tabs are wrong, because different editors will treat them differently.
>> Spaces are right, because a space is a space is a space,  everywhere
>> you go. 
> There are actually two things involved here.
> If you use tabs everywhere for indentation (i.e. tab *characters*, not
> tab *stops*) you are guaranteed that you can cut and paste from any
> other source code that uses tabs everywhere, even if it doesn't look
> right onscreen (because they used a different tab size).
> If you use spaces everywhere, you are at the mercy of other code that
> doesn't use the *same number* of spaces for indentation. For example,
> if you use four spaces for indentation, and you cut and paste code that
> uses two spaces per indentation, nothing will work. You will need to
> reformat one or the other before copying the code.

thats not so a big problem. you can mix diffrent indentation withs even 
within a function. the point is that a block must keep its indentation and 
that deeper blocks are indented a bit more.

e.g this is legal:
>>> def fu(arg):
...    if arg:
...       print "no value"
...    else:
...     print arg

it might not look nice, but its valid.

> And of course, any time you mix spaces and tabs for indentation you
> might as well forget it completely.
> The problem is simply that people use the tab key and character to mean
> different things. Originally the tab key was designed to do the same
> thing as on a typewriter - advance to the next tab stop (i.e. a certain
> number of spaces). Thus you end up with editors which distinguish
> between indentation and tab because a tab is too big for indentation.
> It would have been so much easier if it had originally been defined
> that the tab key always generated a tab *character*, and that the tab
> *character* had been defined as equivalent in size to four spaces (or 3
> perhaps). This rule of course would be broken by applications which can
> set their own tab stops, but that's up to the application. The
> important thing is that there should *always* be a direct mapping
> between the tab key and the tab character. 

tabs are specified as 8 characters. only programmers that use tabs to 
indent make them 4 or 3 characters...
tabs were defined to make a formated output. e.g. you can write zero to 7 
characters plus a tab and you know where the cursor is. this is nice for 
tables on ASCII/text only outputs. a tab with of 4 would make the original 
idea of tabs complete useless.

a "tab *charcter*" that is just a shorthand for four spaces is completly 
useless (unless for data compression, but there are better algos...)

the Java styleguide says that you should use 4 characters indentation and 
that you can write a tab for 8 characters, so they made it correct, same as 
python has it correct too.

> Tim Delaney

Chris <cliechti at>

More information about the Python-list mailing list