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/