Non-Indented python

[Michael Abbott]

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote in
news:slrna0f2eh.uit.qrczak at qrnik.zagroda: 

> Fri, 30 Nov 2001 12:13:20 +0000 (UTC), Michael Abbott
> <michael at rcp.co.uk> pisze: 
> 
>>> This problem doesn't exist if you use 8 as the tab width because then
>>> the apperance is consistent with semantics. 
>> 
>> Until you (or, more likely, someone else) run the source through an
>> editor which happens to be configured for a different tab size 
> 
> That's what I said: the problem doesn't exist if the tab size is always
> kept at 8. It doesn't matter how many times indents are converted
> between tabs and spaces, and what the tab key inserts, and whether
> indents are consistently made of spaces or tabs or they are mixed.
> 
> There is no need to ban tabs, or to ban spaces, or to ban mixing
> indents (whether it's mixing tabs with spaces on the same line or
> mixing indentation methods on differnent lines belonging to the same
> block). Just ban non-standard tab sizes and the problem is solved.
> 

Well, you have to ban something.

The problem with banning non-standard tab sizes is that as soon as someone 
makes a small mistake you can have a real mess to deal with.

As I related, the problem with the trashed C file was a real pain, and I 
don't think the mess was ever cleaned up (I never had occasion to modify 
the ruined code, so I never took the time to clean up the ruined 
indentation).

Unless you mandate that everyone runs the same editor as you do, tabs are 
going to trip you up.

What is the point of using hard tabs, anyway?  I've never understood what 
purpose they serve in source code.  They simply add an invisible source of 
possible confusion.