Non-Indented python

[Delaney, Timothy]

> From: Jeff Shannon [mailto:jeff at ccvcorp.com]
> 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.

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.

Tim Delaney