A modest indentation proposal

[Lucio Torre]

Erann,

Just to let you see how the only important thing is indentation, we are 
going to remove the colon when opening a block.

Seriously, if coherent design is a concern to any of you, please let me 
know why a block starting colon is proper, but a block closing elemnt is 
not.

Lucio.

Erann Gat wrote:

>In article <3C0773C2.A12D0BAC at pacific.net.hk>, Bernie
><bernie at pacific.net.hk> wrote:
>
>>Erann, I think you find the indentation annoying because you choose 2 spaces 
>>as your tab size, hence making the block not as apparent as it could 
>>be.  Try four spaces, or use Tools/Scripts/pindent.py if you really cannot 
>>stand it.
>>
>
>No, that's not it.  Let me explain that remark, but first let me say the
>following:
>
>  *** I am not suggesting the semicolon rule to replace syntactically
>  *** significant indentation, but merely to augment it.
>
>Here's what I find annoying:
>
>Consider the following code:
>
>biff()        # Line 0
>for x in l:   # Line 1
>  foo()       # Line 2
>  baz()       # Line 3
>bar()         # Line 4
>
>When I use python-mode in emacs the editor will automatically indent for
>me after line 1.  In fact, if I screw up the indentation accidentally,
>emacs can automatically restore it in the above example except for line
>4.  The reason it can do that is because of the colon at the end of line
>1.  That colon is actually redundant.  It tells you unambiguously that the
>next line must be indented or you have a syntax error.  I consider this
>redundancy, and emacs's resulting ability to automatically reconstruct the
>indentation to be a feature.
>
>The reason emacs can't restore the indentation on line 4 is that there is
>no such redundant information for emacs to use to determine where a block
>ends.  People have suggested a convention like:
>
>
>biff()        # Line 0
>for x in l:   # Line 1
>  foo()       # Line 2
>  baz()       # Line 3
># end for
>bar()         # Line 4
>
>What I am suggesting is no different, except that instead of "# end for" I
>want to use ";".  The reason is simple: it's less typing, and it's easier
>to modify emacs python-mode to detect a trailing semicolon than an
>end-block comment.
>
>There is in fact already a hack for this.  I could write:
>
>
>biff()        # Line 0
>for x in l:   # Line 1
>  foo()       # Line 2
>  baz()       # Line 3
>  pass
>bar()         # Line 4
>
>
>and emacs will re-indent line 4 properly.  RETURN also serves to
>unambiguously mark the end of a block.  But IMO putting in pass statements
>all over the place to mark the end of blocks is really ugly.
>
>I'd also like to respond to a few other comments:
>
>* Steve Lamb:
>
>>>It also IMO makes the language unsuitable for mission-critical applications.
>>>It's just too easy to screw up indentation (particularly when cutting and
>>>pasting large blocks of code) without realizing it.
>>>
>
>> Hogwash, plain and simple.  Either you know it because it is visually
>>different or you know it when you test the application and it fails
>>spectacularly.  You /do/ test your mission-critical applications, don't you?
>>
>
>Yes, of course we test our mission critical applications.  Please extend
>me the courtesy of not immediately assuming I'm an idiot just because I
>make a proposal that you don't like.  But testing is actually a very
>ineffective way of insuring that software works, particularly
>mission-critical software.  For one thing, it's not possible to test
>spacecraft software under field conditions until the spacecraft is
>launched, and by then it may be too late.  For another, many bugs,
>particularly in real-time multithreaded systems, are probabilistic, and so
>even if your tests work perfectly that alone does not provide a lot of
>confidence that your software is in fact correct.
>
>* Skip Montaro:
>
>>As has been demonstrated many a time, you're more likely to screw up a C
>>block by omitting braces:
>>
>>   if (cond)
>>       x = 1;
>>       y = 1;
>>
>
>Yes, this is exactly my point.  You can look at the above code and tell
>there's something wrong because the braces and indentation provide
>redundant information in C.
>
>* Skip:
>
>>In fact, it's such an insidious
>>problem in C code that many groups mandate that all blocks use { & }, even
>>for one-statement blocks.
>>
>
>Yes, and the situation in Python is that the language mandates an
>open-brace (or it's equivalent, the colon) and doesn't provide a
>close-brace even as an option.
>
>>In Python, if it looks right, it is right.
>>
>
>No, that's not true.  Consider the following two alternative code fragments:
>
>if x:
>  foo()
>baz()
>
>if x:
>  foo()
>  baz()
>
>They both look right, but they can't both be right.
>
>* Skip:
>
>>   Erann> This convention is 100% backwards-compatible with current
>>   Erann> practice, that is, code written using this convention runs with
>>   Erann> no problems in Python as it currently stands.
>>
>>Not it's not.  Semicolons can legitimately be used to end a statement now.
>>
>
>Well, that's actually what I meant by "backwards compatible."  I know that
>semicolons can be used at the end of statements, but at the moment doing
>so is a no-op.  (All it does is betray you as still thinking in C/Java.) 
>I want to take syntax that is currently legal but useless and make it
>useful.
>
>Look, the reason I made this proposal is not that I want to come in and
>tell the Python community that syntactically significant indentation is
>all screwed up and should be discarded.  The reason is that I want to sell
>people at JPL on the idea of using Python to write mission-critical
>software, and the people I'm trying to sell are raising this objection.  I
>can counter this objection, but only three-quarters of the way.  I can
>point out that Python already provides enough redundant information to
>reconstruct corrupted indentation at the beginning of blocks, but not at
>the end.  To reconstruct it at the end of blocks all I can offer is my
>"pass/return" hack.  I'd really like to be able to offer a standard
>syntactic convention that is endorsed by the Python community.  That would
>make Python a lot easier to sell.
>
>So lighten up, folks.  We're on the same side.
>
>Erann Gat
>gat at jpl.nasa.gov
>