Little red lines in PythonWin!

[Dave LeBlanc]

Ugh - take it all back! I wuz wrong!

\t\s != \s\t since \t\s is (# of tabspaces + \s) and \s\t is only (#
of tabspaces - leading \s) since it "rounds off" to the multiple and
therefore the # of spaces inserted varies depending on leading spaces.

My bad - sincere apologies. I'll study Perl in penance.

Dave LeBlanc


On 21 Mar 2001 03:49:22 GMT, whisper at oz.net (Dave LeBlanc) wrote:

>>"... 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.
>>
>