On Sun, Sep 21, 2008 at 12:52 PM, Arnaud Delobelle email@example.com wrote:
On 21 Sep 2008, at 20:24, Josiah Carlson wrote:
Not all statements; all *control flow* statements. Return, yield, continue, break, assert, ..., can all change program flow. To say that break and continue should be special cased is silly, as "Special cases aren't special enough to break the rules". As such, why continue and break but not return or yield? Further, the syntax is *so very similar* to conditional expressions <X> if <C> vs. <X> if <C> else <Y>, the lack of an else clause could be confusing to those who have seen and used conditional expressions before, never mind the meaning of them.
Well my view was that break and continue are the only two statements that relate to loops. [...]
Superficially yes, but the execution of raise, return or yield can result in the loop never completing another pass. That a loop can occur in an except clause even offers the ability for the no-argument raise to make sense even there ;) .
I don't agree with that: the absence of do .. while liberates the loop construct in python from its constraints and the first form above becomes more common.
But you were just arguing that the *lack* of do/while makes the embedded if necessary. Now you are saying that it *liberates* us from the control-flow induced by do/while. ;) There's an argument that says rather than treat the symptom (breaks in the body), treat the disease (lack of a do/while). But since the lack of a do/while isn't a disease, by your own words, then the symptom is not a bug, it's a feature ;)
There is a missing link in your interpretation of my argumentation. It is that I haved noticed that, as I do not have a do .. while construct at my disposal in Python, I do not try to shape my loops into this structure anymore. I almost *never* write:
while True: ... if condition: break
But most of the time it seems that the correct structure for a loop comes as
while True: ... if condition: break ...
That also has a translation with the "first" idiom, though it's a bit uglier (no, really):
first = 1 while first or condition: if not first: ... first = 0 ...
Really though, what is pretty/elegant really varies depending on what those ... turn into. To be honest, I've only ever used the above once or twice, though the standard first idiom I've used dozens of times. Though if you really want to have fun, there's nothing like exploiting while loops for checking error conditions. ;)
def foo(...): first = 1 while first: first = 0 if error_condition1: break ... #other error conditions, processing, whatever else: #only executes if everything is ok #error condition