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]>