Little red lines in PythonWin!

Dave LeBlanc whisper at oz.net
Wed Mar 21 04:49:22 CET 2001


>"... if spaces get mixed in it's bound to cause problems.  So in
>general that's nasty..."

Urban legend perhaps?

Seems like, so long as you actually indent dependent lines, such as
those comprising the body of an if statement, as little as one space
or tab character then you're legal.

So long as a text processor expands tabs to the same number of spaces,
then I don't see how any tab+space sequence that only varies by the
number of explicit space characters can ever possibly result in the
same or less whitespace to the left of text on a line. This makes it
hard to understand why one wouldn't want to use a mix of tabs and
spaces, especially "because of the nature of text editors on non-UNIX
platforms" (quote from 2.1.7).

\t\t\t\s\s\s and \s\s\s\t\t\t where \t --> \s\s\s\s (and \s represents
a single space character) will always create the same amount of space
in any text editor (as contrasted to a word processor) i've ever used
on a wide variety of OSs, including places where sp != 0x20 and tab !=
0x09 (EBCDIC et al.). Even text editors that allow the use of
proportional fonts seem to have a fixed idea of the screen area taken
up by a space character. (People who use word processors for text
editing, especially source code, deserve what they get.)

Frankly, using that many spaces (8) to indent seems like a waste of
screen real estate, not to mention making the code actually harder to
read. Perhaps 8 spaces/tab made sense when the primary output medium
was a decwriter or a tty, which was the last time I used so many
spaces to replace a tab, but not anymore.

Just my opinion...

Dave LeBlanc

On 20 Mar 2001 14:49:14 -0500, David Bolen <db3l at fitlinxx.com> wrote:

>In theory you really shouldn't get into trouble using tabs as long as
>you follow Python's parser definition of what a tab is (treat as
>moving to next multiple of 8 - Language Reference 2.1.7).  The trouble
>is mostly when an editor is using an explicit tab character but
>internally adjusting its dimension to something other than that rule.
>Even that might work as long as only tabs are used for indentation,
>but if spaces get mixed in it's bound to cause problems.  So in
>general that's nasty, but as long as you untabify in that same
>editor/IDE before distribution, since it knows its own rules, the
>untabified version should be fine.
>




More information about the Python-list mailing list