[Python-ideas] Updating PEP 315: do-while loops
larry at hastings.org
Sun Apr 26 14:31:22 CEST 2009
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
> 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:
} while (condition);
As viewed through my "Python glasses" becomes this:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas