tabbing probs (was: Prothon Prototypes vs Python Classes)

Michael mogmios at
Mon Mar 29 18:03:25 CEST 2004

>I think you misunderstood. There is no "standard" length of
>a tab. A tab is supposed to insert (or otherwise render the
>equivalent of inserting) enough spaces to go to the next "tab stop",
>which by convention is a multiple of 8 columns on a fixed
>width mechanical typewriter. This is where tabs originated.
No, I just fail to see why it matters. A tab could be 4 columns, 8 
columns, 15 columns, or whatever on a particular editor and code blocks 
will still line up.

>It matters. 8 columns is much too wide for indents in readable code.
>People do differ on that, but that seems to be the concensus.
So rather than switch editors or change your editors settings you'd 
rather everyone be forced to use spaces? I presume four spaces? If 
someone uses eight spaces to indent will that also break the code? It 
seems to me that it'd be easier to configure an editor to show tabs as 
four columns, if you so desire, than to configure an editor to show 
eight spaces as four columns. Eight spaces is no easier to read than a 
tab that takes eight columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent rather than 
tabs, then I'll most likely use a single space to indent because I don't 
want to deal with pressing the space and backspace keys multiple times 
(trying to keep count) to make blocks line up correctly. I also don't 
find it acceptable to use an editor which kludges together such space 
using behavior for me to do what tabs would have done in the first 
place. Overall, I think I find code that uses a single tab, rather than 
a single space, to be easier to read.

More information about the Python-list mailing list