<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Mike Meyer wrote:
<blockquote cite="mid:20090426011259.58c52c9e@bhuda.mired.org"
  <blockquote type="cite">
    <pre wrap="">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.  
  <pre wrap=""><!---->No, it isn't. Well, it wasn't originally, but got hijacked into being
that. More on the original in a minute.
<blockquote type="cite">
  <pre wrap="">Minor spelling variants (which is what these are)
are pretty much poison as far as readability is concerned, and are

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.<br>
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.<br>
<blockquote cite="mid:20090426011259.58c52c9e@bhuda.mired.org"
  <pre wrap="">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.</pre>
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".<br>
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:<br>
  * Start with the C form, in K&R spelling, with curly braces.<br>
  * Replace the opening curly brace with a colon.<br>
  * Remove the closing curly brace entirely, and any non-newline
whitespace after it.<br>
  * Remove the parentheses around the conditional expression.<br>
  * Remove semicolons.<br>
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".<br>
So let's apply it to the C do/while loop.  This:<br>
<blockquote>do {<br>
} while (condition);<br>
As viewed through my "Python glasses" becomes this:<br>
while condition<br>
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:".<br>
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.<br>
I therefore assert this syntax is optimal; certainly I doubt anyone
will suggest one I'd like more.<br>
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.<br>