Python Rocks!

Neel Krishnaswami neelk at brick.cswv.com
Tue Jan 18 20:53:33 EST 2000


tye4 <tye4 at yahoo.com> wrote:
> 
> So you don't think this is a problem?? Hello!, read all the messages in this
> thread. Seems to me a lot of programmers have a problem with this.
> Thanks to this quirk, I now have to worry how an editor saves tabs to files.
> I have offered you many reasons why we need 'end' block support..
> You have not offered a single reason why this is not a problem..

My other language-of-choice, Dylan, has a syntax and level of
expressive power very similar to Python's, except that it has "end"
block delimiters.

The Gwydion Dylan compiler is about 56,000 lines of non-comment
non-blank lines. Of these 56 KLOC, 8700 contain only "end" statements.
That's about 16% of the code, or 1 line in 6. Presumably a similar
fraction of Python code would be end statements if Python had block
delimiters too.

It's also well-known that the average time to debug a function or
class goes up with length, with a sharp upwards kink when the length
of the program object exceeds 1 screenful, *whatever the screen size
is*.

Let's suppose that we are editing on a terminal that has 42 horizontal
lines. Then adding block delimiters to Python would mean that the
effective screen size would shrink from 42 currently to 35 plus
delimiters. This is a *painful* loss, considering that the debug time
kinks upward whenever a program exceeds one screenful in size.
Consequently, I think Guido made an excellent choice in keeping block
delimiters out of Python. The gain in readability is well worth the
slight inconvenience of dealing with tabs.

(BTW, I also think Dylan did the right thing, because the block
delimiters in Dylan are mostly there to make it possible to have a
hygienic macro facility. Since Python doesn't have this, it doesn't
need gratuitous "end" statements.)


Neel



More information about the Python-list mailing list