A modest indentation proposal

[Erann Gat]

The subject of syntactically-significant indentation seems to dominate a
lot of discussions on Python.  Personally I've found it to be less of a
problem than I thought it would be, but annoying nonetheless.  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.

I have a suggestion for how to make people like me who are uneasy with
syntactically significant indentation feel more comfortable while at the
same time not alienating those who thing that it's a really cool feature. 
The proposal is based on the observation that Python already has the
equivalent of an open-brace for code blocks.  It's the colon.  To see that
this is so you have only to observe that a good editor can automatically
indent code properly at the beginnings of blocks, but not at the end.  The
solution to the problem is to add an optional end-of-block identifier.

I propose to use a semicolon at the end of a line to denote the end of a
block, e.g.:

for i in l:        # Colon signals beginning of block
  foo()
  baz(); boff()    # Semicolon separating statements works as usual
  bar();           # Semicolon at end of line signals end of block
biff()


This convention is 100% backwards-compatible with current practice, that
is, code written using this convention runs with no problems in Python as
it currently stands.

What I would like to see in terms of support for this convention from the
Python community is two things:

1) Editor support for this convention so that a semicolon at the end of a
line causes the editor to unindent, and

2) Parser support.  It would be enough to simply give a warning if there
is a discrepancy between the block structure defined by indentation and
that defined by the semicolon-at-end-of-line convention (i.e. "Warning:
end of block detected without trailing semicolon").  Making this optional
so that die-hard indentation fans could turn it off would also be fine.

Comments?

Erann Gat
gat at jpl.nasa.gov