[Python-ideas] An Alternate Suite Delineation Syntax For Python? (was Re: [Python-Dev] [PATCH] Adding braces to __future__)

[Nick Coghlan]

On Sun, Dec 11, 2011 at 11:55 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> Mike Meyer wrote:
>
>> Since you sent it to Python-ideas, I'm going to assume you were at
>> least semi-serious. So let me add the use case I came up with while
>> reading the original post, also often seen in template languages:
>>
>>    Writing code to generate python.
>>
>> With significant whitespace, you have to keep explicit track of the
>> current nesting level in order to generate the appropriate
>> indent. With real delimiters, you can drop that. Compare:
>
>
> That's hardly an onerous requirement. As you show, the two code snippets are
> almost identical, except that the indent version takes an explicit level
> argument, while your braces version neglects to close suites at all. A fair
> comparison should show the close-suite code, even if it is only a single
> line.

Indeed, that's a reason I didn't use straight up code generation as my
motivating use case - the significant whitespace simply isn't that
painful in that case. The reason significant leading whitespace can be
a PITA is due to two main circumstances:

1. Attempting to transport it through a channel that either strips
leading and trailing whitespace from lines, or else consolidates
certain whitespace sequences into a single whitespace character
(generally sequences of spaces and tabs becoming a single space).
Python source code simply cannot be passed through such channels
correctly - if they don't offer an escaping mechanism, or that
mechanism is not applied correctly, the code *will* be corrupted.
Explicitly delimited code, on the other hand, can be passed through
without semantic alteration (even if the details of the whitespace
change) and a pretty printer can fix it at the far end.

2. Attempting to transport it through a channel where leading
whitespace already has another meaning. This comes up primarily with
templating languages - your whitespace is generally part of the
template output, so it becomes problematic to break up your Python
code across multiple code snippets while keeping the suite groupings
clear. With explicit delimiters, though, you can just ignore the
template parts, and pretend the code snippets are all part of a single
string (the following is based on an example a colleague sent me [1],
with the closing delimiter adjusted to mirror the opening one as a
couple of folks suggested):

<% if danger_level > 3 {: %>
  <div class="alert"><% if danger_level == 5 {: %>EXTREME <% :}
%>DANGER ALERT!</div>

<% elif danger_level > 0 {: %>
  <div>Some chance of danger</div>

<% else {: %>
  <div>No danger</div>

<% :} %>

<% for a in ['cat', 'dog', 'rabbit'] {: %>
  <h2><%= a %></h2>
  <p><%= describe_animal(a) %></p>

<% :} %>

[1] https://gist.github.com/1455210

Is such code as beautiful and readable as normal Python code? No, of
course not. But it would serve a purpose in defining a *standard* way
to embed Python code in environments where the leading whitespace
causes problems.

In terms of how such a delimited syntax would relate to currently
legal Python code, the transformation is basically the reverse of the
Haskell one:

1. If you encounter a ":" to open a new suite, replace it and any
trailing whitespace with "{:".
2. All whitespace between statements in such a suite is replaced with
";" characters
3. Any trailing whitespace after the last statement in the suite is
replaced with ":};"

The rest of the changes (i.e. a suite's expression value being the
result of the last statement executed, anonymous function and class
definitions) then follow from the fact that you now have a suite
syntax that can potentially be embedded as an expression, so a range
of new possibilities open up.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia