[Python-ideas] Updating PEP 315: do-while loops

[Larry Hastings]

Mike Meyer wrote:
>> It's true, "break if <condition>" and "continue if <condition>" are 
>> redundant constructs.  But this debate is over refining our syntactic 
>> sugar--charting what is arguably a redundant construct.  
>>     
> No, it isn't. Well, it wasn't originally, but got hijacked into being
> that. More on the original in a minute.
>   
[...]
> Minor spelling variants (which is what these are)
> are pretty much poison as far as readability is concerned, and are
> unPythonic.
>
> The original proposal - while it was syntactic sugar of sorts - dealt
> with a real issue: Python doesn't have a natural loop construct for
> the common case of having a conditional at the bottom. The existing
> conditional loop can be coerced into that role in a couple of ways,
> but all of them have problems.
>   

I don't follow the distinction you draw.  In what way is do-while not 
straight syntactic sugar?  We can already express the construct with 
"while True: ... if not <expression>: break".  There's nothing unnatural 
about spelling it this way, and it's worked for longer than either of us 
have been using Python.

So, from my perspective, the proposal is *asking* for redundant syntax. 
  And therefore describing my suggestions as "unPythonic" and "pure 
poison" because they're redundant is sophistry.

> The proposed solution puts the conditional at the top, which is pretty
> much mandated by existing python control flow syntax: control
> constructs appear at the top of blocks, control the code indented
> beneath them, and they are terminated by a dedent (yes, I'm ignoring
> statement stacking). Unfortunately, this solution feels strange, what
> with the conditional at the wrong end of the controlled block.
>
> A syntax that puts the conditional at the bottom end of the controlled
> block either uses a dedent to signal the end of the control block,
> which clashes with existing constructs, or doesn't use such a dedent,
> which means it's trivially turned into conditional in the middle
> construct. Which means - as we've just seen - that it's in danger of
> being a spelling variant of the existing solutions.
>
> What's really needed is a completely different looping construct.

I don't agree with this conclusion.  We're talking about "do/while", 
which is traditionally different from other looping structures.  You 
call that "clashing", I call that its "raison d'etre".

Having slept on it, I think we won't do any better than the usual 
approach for cooking up new Python syntax: view C syntax through 
Python-colored glasses.  I claim this transformation works as follows:
  * Start with the C form, in K&R spelling, with curly braces.
  * Replace the opening curly brace with a colon.
  * Remove the closing curly brace entirely, and any non-newline 
whitespace after it.
  * Remove the parentheses around the conditional expression.
  * Remove semicolons.

Applying that transformatino to C's "if", "if/else", and "while" gives 
us the Python syntax.  And it shows us the way to write "for".

So let's apply it to the C do/while loop.  This:

    do {
        something();
    } while (condition);

As viewed through my "Python glasses" becomes this:

    do:
        something()
    while condition

Yes, it's surprising that there's no colon on the "while" line.  But we 
aren't indenting a new code block, so we shouldn't have a trailing 
colon.  And Python has never used a leading colon to mean "outdent but 
continue the construct"; if it did we'd spell if-else as "if 
<condition>: ... :else:".

If it looks weird to you to have a "while" not followed by a colon... 
good!  do/while is a weird construct.  We should *expect* it to look as 
weird in Python as it does in C.

I therefore assert this syntax is optimal; certainly I doubt anyone will 
suggest one I'd like more.


I still like "break if" and "continue if", but I now see those as 
separate.  And I should not be surprised if they are henceforth 
ignored--as you point out they are wholly redundant.  I think they're 
pleasing in their redundancy but I'm surely in the minority.


/larry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090426/ee45fcbb/attachment.html>