Larry Wall's comment on python...
James J. Besemer
jb at cascade-sys.com
Wed Sep 25 21:45:20 EDT 2002
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
More information about the Python-list
mailing list