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.
-- Arnaud
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?
-- Arnaud
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
-- Arnaud
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