This kragen-tol article was published (with some of the mistakes
removed) in ;login: this month; I had the following interesting
conversation with a reader, which I repost here with his permission.
Date: Thu, 13 Jun 2002 14:32:50 -0700 (PDT)
From: "Simon J. Gerraty" <[EMAIL PROTECTED]>
Subject: Re: python indent sensitive
Hi,
I was reading your article in ;Login: regarding python cf. perl.
In your comments about python being indentation sensitive you
assert that anyone who finds this silly is an unthinking moron.
I recall looking at the python web pages some years ago - since python
sounded cool, and saw a claim that "there is a very good reason
python doesn't use braces", but that reason was never given.
Since you clearly hold that python's indentation sensitivity is a
bonus, perhaps you could explain why - with actual reasons that
is.
Its possible I'm wrong to think that python would have been a very
good language if only it used braces for grouping rather than
indentation, but absent something a bit more convincing than
"its better", I can only imagine it being a source of hard to track bugs.
Thanks
--sjg
Date: Thu, 13 Jun 2002 18:52:15 -0400
From: Kragen Sitaker <[EMAIL PROTECTED]>
Subject: Re: python indent sensitive
Simon J. Gerraty writes:
> I was reading your article in ;Login: regarding python cf. perl.
> In your comments about python being indentation sensitive you
> assert that anyone who finds this silly is an unthinking moron.
I haven't seen the printed version yet, but I think I said that certain
kinds of "unthinking morons" (your words, not mine) didn't like it,
but I specifically said there might be reasons other than being an
"unthinking moron" that one might not like it.
Many people who "unthinkingly adhere to stupid traditions" (my words
from the article) are quite intelligent.
> Since you clearly hold that python's indentation sensitivity is a
> bonus, perhaps you could explain why - with actual reasons that
> is.
With braces, I have to say what I mean twice --- once with the braces,
so the compiler can understand me, and once with indentation, so humans
can understand me. If I get it wrong, I have an unseen bug. As a C,
C++, and Perl programmer, I eventually developed very sharp eyes for
things like this:
if (foo)
debug_printf("foo happened\n");
barf();
do_something_else();
In Python, I don't have to waste my attention on that any more.
Whitespace is a preattentive feature; it is processed by my retina
and visual cortex without any conscious attention on my part and very
little effort, and I can see *all* of the whitespace in a large visual
display in less than a quarter of a second, about the time it takes my
eye to move from one spot to another. It is a major benefit to be able
to understand the nesting structure of a whole screen or page of source
code automatically and with no effort. That is why indentation to show
nesting in source code is universal today.
Python simply removes the possibility that your subconscious, preattentive
understanding of your program's structure is incorrect. Knowing that
a program is written in Python also eliminates the possibility that
it is unindented; an unindented C program can be run through 'indent',
but an unindented Perl program is a nightmare.
People occasionally suggest that this lack of redundancy will lead to
bugs, as a misindented statement won't be noticed later. (Specifically,
a statement that should be inside a block being after the block, or
vice versa.) I've introduced lots of bugs in programs, and I have
kept exhaustive records of the bugs I found in many small programs.
I cannot recall any bugs of this nature in my Python or Perl programs,
but I have introduced this kind of bug a few times in C and C++ programs,
usually in the way shown above.
It is rarely subtle in its effects, but it is often hard to find.
I don't argue that redundancy is always bad, but that in this particular
case, the redundancy proves not to be worth its price.
For my thoughts on when redundancy in syntax (and
programming languages in general) is a good idea, see
http://lists.canonical.org/pipermail/kragen-tol/2002-April/000705.html
"Lisp syntax considered insufficiently redundant" and
http://www.paulgraham.com/redund.html "Redundancy and Power".
Subject: Re: python indent sensitive
Date: Thu, 13 Jun 2002 17:44:08 -0700
From: "Simon J. Gerraty" <[EMAIL PROTECTED]>
Hi, I dropped the login address [the original mail was Cc:ed to
[EMAIL PROTECTED]] - since it was wrong anyway :-)
> > Since you clearly hold that python's indentation sensitivity is a
> > bonus, perhaps you could explain why - with actual reasons that
> > is.
>
> With braces, I have to say what I mean twice --- once with the braces,
> so the compiler can understand me, and once with indentation, so humans
> can understand me. If I get it wrong, I have an unseen bug. As a C,
Hmmm, interesting. I'm thinking more of the case where I put the
braces in and the editor does the indenting for me - emacs, no pain at
all.
Further, while indentation alone may suffice for a screen's worth of
code, I find it inadequate for grossly large blocks of code. Note
that I often have to debug programs written by others so the fact that
a huge function should be re-organized is orthogonal to understanding
what it is doing. Being able to ask a tool like an editor "go show me
where this block started" is very handy. Matching braces etc makes
this easy.
Now of course it could be the case that there is a decent python mode
for emacs that handles all this.
> code automatically and with no effort. That is why indentation to show
> nesting in source code is universal today.
Sure, but using braces makes it simpler to write tools to
munge/analize code. Does python treat a line of code indented with
a TAB differently to code indented with spaces?
> it is unindented; an unindented C program can be run through 'indent',
> but an unindented Perl program is a nightmare.
Yep, any unindented code is a nightmare.
> People occasionally suggest that this lack of redundancy will lead to
> bugs, as a misindented statement won't be noticed later. (Specifically,
> a statement that should be inside a block being after the block, or
> vice versa.) I've introduced lots of bugs in programs, and I have
> kept exhaustive records of the bugs I found in many small programs.
> I cannot recall any bugs of this nature in my Python or Perl programs,
> but I have introduced this kind of bug a few times in C and C++ programs,
> usually in the way shown above.
Again, I'm more concerned about code I didn't write. Anything that
assists me in analyzing the code for bugs is good.
Anyway, thanks for elaborating on "its better".
--sjg
From: [EMAIL PROTECTED] (Kragen Sitaker)
Date: Wed, 19 Jun 2002 15:43:00 -0400 (I think)
Subject: Re: python indent sensitive
You write:
> Hmmm, interesting. I'm thinking more of the case where I put the
> braces in and the editor does the indenting for me - emacs, no pain at
> all.
Well, when you're *writing* code --- typing it out one line after
another --- it's usually not a problem, with or without braces. It's
when you're *editing* code that the problem comes up. In Emacs, at
least, I experience some pain when you're creating or deleting blocks
around existing code; sometimes I revert to C-n TAB C-n TAB, but there
is of course M-C-\, which requires me to select the affected code
first, after having already added or deleted braces. In Python, I
typically select the affected code and hit C-c > or C-c <.
I should record an editing session sometime to identify the particular
transformations I'm really performing instead of the ones that come to
mind.
When you're *reading* code, the braces just take up space without
conveying any information not already conveyed by the whitespace.
> Further, while indentation alone may suffice for a screen's worth of
> code, I find it inadequate for grossly large blocks of code.
Meaning that you need both block structure and editor support for it?
> Note that I often have to debug programs written by others so the
> fact that a huge function should be re-organized is orthogonal to
> understanding what it is doing. Being able to ask a tool like an
> editor "go show me where this block started" is very handy.
> Matching braces etc makes this easy.
Well, unfortunately forward-sexp and backward-sexp don't think Python
blocks are sexps, but when I want to know where a block began, I
usually move to the end, hit Enter, then hit Backspace a few times.
Each Backspace moves me back one indent level (like } in C-mode with
auto-mode turned on) and prints a line in the minibuffer telling me
where the block I'm closing began. This isn't ideal, but it's usually
good enough.
Someone has hacked up an outline minor-mode for Python thet lets you
collapse functions and classes; I wish I had something like that for
arbitrary blocks.
> Sure, but using braces makes it simpler to write tools to
> munge/analize code. Does python treat a line of code indented with
> a TAB differently to code indented with spaces?
It treats it as if it had been run through 'expand -8'.
I often find indentation more useful for writing automated tools, too;
questions like the following are easier to answer by indentation than
by parsing. (They all can get fouled up by Python's multiline
strings, though, because those can be arbitrarily indented or
outdented.)
- what are the top-level constructs in this module?
- what are the global functions defined in this module?
- what lines of code are conditional on the variable DEBUG?
You can do shallow processing like this correctly without parsing the
code (just tokenizing it) if you have indentation to help you.
I originally posted the comparison article to a mailing list of my
own; would you mind if I forwarded this conversation about it to the
list too?
Subject: Re: python indent sensitive
Date: Wed, 19 Jun 2002 15:54:08 -0700
From: "Simon J. Gerraty" <[EMAIL PROTECTED]>
> > Further, while indentation alone may suffice for a screen's worth of
> > code, I find it inadequate for grossly large blocks of code.
>
> Meaning that you need both block structure and editor support for it?
Not sure I follow.
> > Note that I often have to debug programs written by others so the
> > fact that a huge function should be re-organized is orthogonal to
> > understanding what it is doing. Being able to ask a tool like an
> > editor "go show me where this block started" is very handy.
> > Matching braces etc makes this easy.
>
> Well, unfortunately forward-sexp and backward-sexp don't think Python
> blocks are sexps, but when I want to know where a block began, I
I guess that's my point. A little ginger bread like braces would
make python look a bit more like other langs that emacs groks well.
> I originally posted the comparison article to a mailing list of my
> own; would you mind if I forwarded this conversation about it to the
> list too?
Sure, no problem.
--sjg
--
<[EMAIL PROTECTED]> Kragen Sitaker <http://www.pobox.com/~kragen/>
A good conversation and even lengthy and heated conversations are probably
some of the most important pointful things I can think of. They are the
antithesis of pointlessness! -- Matt O'Connor <[EMAIL PROTECTED]>
