Indentation and grouping proposal

[Tim Peters]

[Tim, lying thru his teeth again, claims ...]
>> [R Wentworth, suggests "_(" and ")_" as alternative grouping constructs]
>> Note that this won't fly, since "_(" already has a meaning in
>> the grammar (call the function whose name is _).

[R Wentworth, the offended party, retaliates]
> Actually, the suggested tokens were _{ and }_, with braces rather than
> parentheses.  Admittedly braces and parenthesis can be hard to distinguish
> on a computer screen.  I'm well aware that "_(" is syntactically
> legal and meaningful, and therefore not a candidate.

Blame it on old eyes and a terrible email font -- both on my end.  OK, it's
"_{" and "}_" that will never make it in <wink>.

[notes that pindent.py & one of Donald's old patches ...]

> [do] not allow for 1-line programs.

Let's skip to:

> So, I guess having this "blessed" is unlikely. :(

Exceedingly, yes.  That was the point in trotting out (just a few of the)
previous attempts -- not that their details are in any way superior to your
proposal, but that this kind of suggestion is as old as Python and has never
made progress.

> (I do suspect that the "embedding" issue is more important now than it
> was five years ago, what with the rise of HTML templating systems and
> the like.  To my mind that makes the issue somewhat less frivolous.  Oh,
> well.)

Christian (Tismer) once invented a cute scheme, sticking a number of periods
at the start of each stmt equal to the stmt's intended indent level.  This
preserved his Python programs on a server that stripped leading whitespace,
at the cost of a trivial preprocessing step.  pyindent can also be used in a
similar fashion.  IIRC,

[
>> IIRC,

> "IIRC" ?

If I Remember/Recall Correctly
]

that flavor of server later stopped destroying whitespace, rendering the
scheme moot.  The Perlish urge to write a bunch of stuff on one line anyway
can be resisted, with practice <wink>.  And if codegen is properly
abstracted at the start (via open_block() & close_block() calls, etc),
generating appropriate whitespace is really no harder than generating
visible bracketing glyphs.

Granted that some people don't-- and never will --*like* whitespace, the
notion that there's a killer *technical* argument (on either side) is pretty
much hogwash.  Python's decision was inherited from ABC, where usability
studies with newbies concluded that grouping via indentation was easier to
learn and less likely to confuse.  That's where the colon after
block-opening stmts comes from too, despite that the grammar almost never
really *needs* it.

>> Steven Majewski christened the alternatives "frowning Guidos", in
>> honor of everyone's favorite some 5 years ago:
>>
>>     if whatever :(
>>     print "no whitespace!" ):

> Plausible, if inauspicious.

More than plausible, I believe it got fully implemented.  Wasn't able to
find the patches, though.

although-did-not-suffer-a-coronary-occlusion-from-trying-ly y'rs  - tim