Larry Wall's comment on python...

[James J. Besemer]

sismex01 at hebmex.com wrote:

>>Ironically, Guido originally ruled (in the style guide, IIRC) 
>>that thou shalt use tabs and tabs are 8 spaces, "as god
>>intentended them to be."
>>    
>>
>
>Yeesh! Why in God's name would he say such a dumb thing?
>I mean, even ancient mechanical typewriters have movable
>tab settings. Rigid, 8-char tabs is just so... neolithical.
>

Once upon a time, a large class of computers, and their attendant 
peripherals, OSs and utility programs universally implemented tabs 
hard-wired at 8 stops.  In some circles this heritage extended back 30 
or 40 years.  Unix originally followed this convention, as did IIRC all 
Dec computers and that of most other "minicomputer" vendors.  Ed and the 
original VI editors only had fixed tab stops consistent with terminal 
drivers and all the unit record equipment at the time.  IIRC, even Emacs 
originally only had tab stops at every 8 columns.  The original PC also 
followed this convention, though not all applications did.  I don't know 
for sure but I bet $1 that Linux tty drivers today also are hard wired 
at 8 char tab stops.

Now, if you've ever worked in an environment where EVERYBODY uses the 
same tab stops then you'd probably agree that tabs are vastly superior 
to spaces.  I don't think there's any question.  I presume it's from 
this perspective that the right honorable BDFL issued his original 
proclamation, which is actually quite reasonable, especially from my old 
fart's perspective.

In fact, problems only arise when alternative, competing tab stop 
conventions try to coexist, which I agree is not  generally solvable. 
 Closest solution I've seen is some sites where everybody uses Emacs and 
employ coding conventions so that on startup Emacs can read a specially 
coded comment and automatically switch to the proper indent for that 
file.  This can sort of work but your printer and other rendering 
utilities also all have to recognize the codes.  Spaces are a more 
practical solution.  

I myself still prefer tabs as I find "indenting" and "out denting" 
sections of code to be a common operation (in Python and in other 
languages).  Inserting or removing an "if" or changing inline code to a 
function makes indenting and out denting a common operation.  In the 
environments I use, this works well with tabs and not so well or at all 
with spaces.  By default, I still prefer 8 char stops but I also find I 
can live just fine with 4.  But I can't stand it without tabs.  I'll 
convert to spaces if I need to when delivering code but I can't work on 
it that way.

Anyway, what's wrong with the "neolithical" 8 char stops?  For several 
decades, all the C code ever written was tab indented at 8 columns, 
along with most of the text and other programming languages on Unix. 
 Some people complained that in practice 8 char tabs forced them to 
indent too much and their programs got squashed off the right edge of 
the page.  I have little sympathy for that argument, as I feel if your 
program is properly modularized then then this should not be much of a 
problem as individual modules should not have to be indented all that 
much.  Also, I suspect part of the pressure came from Pascal users, 
where some coding conventions require indenting two levels, once for the 
begin/end pairs and again a second time for the code contained between 
them.  What a crock.  

For what it's worth, Python's C implementation today appears to be tab 
indented to 8 columns, at least all the parts I've looked at.  The main 
interpreter loop is a good example of a "complex" piece of code.  The 
innermost loop includes a single switch statement that's over 1400 lines 
long!  Surrounding logic require that the switch statement and case 
labels start 2 tab stops in and thus the body of each case starts 3 
stops in or in column 24.  Yikes, that's like 1/3 of the total.  And yet 
none of the case bodies extend past column 73 or so.  Turns out that in 
practice most code lines are pretty short.  The ones that aren't 
typically are function calls with multiple arguments, and these may 
easily be split onto multiple lines (often thereby increasing 
readability).  Since Guido personally wrote the bulk of this system as a 
labor of love, I surmise that he's still pretty sentimental about the 
old ways.

Regards

--jb


-- 
James J. Besemer		503-280-0838 voice
2727 NE Skidmore St.		503-280-0375 fax
Portland, Oregon 97211-6557	mailto:jb at cascade-sys.com
				http://cascade-sys.com