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. [...]
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 ...
In fact, I would be happy with getting rid of the while loop and replacing it with a simple 'loop' constuct, where:
while condition: ...
would be written as:
loop: if condition: break ...
However I see this as too radical to propose :)
Which *has* an idiom in Python.
first = 1 while first or condition: first = 0 ...
I would not use this, not because it is slower, but because it is uglier.
That's funny, because whenever I use it in a production codebase, coworkers always comment how they like it because it pushes the condition for the loop at the loop header rather than embedding it in the (sometimes long) body. In particular, I've seen the lack of a do-while in Python result in an if clause at the bottom of a 150 line while, which had been confusing as hell for anyone who got to touch that code. Moving it up to the top made it clear and resulted in a removal of half a dozen lines of comments at the top explaining why the loop was constructed like this. After the above translation, those comments became "this emulates a do-while clause".
This makes a lot of sense, if you use a do .. while concept in your loops. Now I feel bad that I used the word "uglier" ...
Anyway, there hasn't been a flurry of positive responses so far so I don't think this is going to go much further than this reply...
Syntax changes are tough to get agreement on in Python.
Thank you for your comments, they all make a lot of sense.
On Sun, Sep 21, 2008 at 12:52 PM, Arnaud Delobelle arnodel@googlemail.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
- Josiah
On 21 Sep 2008, at 21:24, Josiah Carlson wrote: [...]
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
Why not write:
def foo(...): while True: if error_condition1: break # Other error conditions, processing, etc # only executes if everything is OK # Error condition
Is there something that I don't see?
There's a missing 'return' in my last post!
On 21 Sep 2008, at 22:10, Arnaud Delobelle wrote:
def foo(...): while True: if error_condition1: break # Other error conditions, processing, etc # only executes if everything is OK
return
# Error condition
On Sun, Sep 21, 2008 at 3:13 PM, Arnaud Delobelle arnodel@googlemail.com wrote:
There's a missing 'return' in my last post!
On 21 Sep 2008, at 22:10, Arnaud Delobelle wrote:
def foo(...): while True: if error_condition1: break # Other error conditions, processing, etc # only executes if everything is OK
return# Error condition
Short answer: there are many variants, not all of them can be translated into the above.
- Josiah
-
Arnaud Delobelle -
Josiah Carlson