On 26 Apr 2009, at 21:20, Larry Hastings wrote:

Anyway, this is one reason why I like the "do:" statement I proposed. (The other one--the one where I also proposed "continue if" and "break if". But given your reaction to those let's ignore 'em for now.) This isn't *pure* sugar--it's a mildly novel flow control construct for structured programming. Certainly Python doesn't have anything like it right now; "while True:" isn't an exact match (and "while False:" is equivalent to "if 0:"). My "do:" would allow spelling do/while as:

do: something() if condition: continue

I think that's a reasonable do/while, and so economical: we only added one new keyword. This form of "do:" has other uses too, as per my previous email.

Not that I expect this syntax to take the world by storm.

It's funny because I had something like this in mind when I myself suggested 'break if ...' and 'continue if ...' a little while ago (although I would go for a 'loop:' that doesn't need to be continue'd explicitely). I had come to the point of view that the restrictions of the looping construct had in fact somehow liberated it and made it more versatile by making if condition: break and if condition: continue common control flow constructs inside a while loop, that in particular encompass the do ... while / repeat ... until constructs, etc seen in other languages (I may have expressed myself better in the original thread). My motivation for 'break/continue if ...' was that it would make those constructs stand out more (and could be hilighted clearly as such in editors) - I was a bit surprised when I was told it would make code less readable and that it was a slippery slope, but then I have lots of ideas, most of which don't turn out to be very good :) -- Arnaud

[Aahz]

Because I can't resist:

do-while diddy diddy dum diddy do

:-)

Arnaud Delobelle wrote:

On 26 Apr 2009, at 21:20, Larry Hastings wrote:

...

Anyway, this is one reason why I like the "do:" statement I proposed. (The other one--the one where I also proposed "continue if" and "break if". But given your reaction to those let's ignore 'em for now.) This isn't *pure* sugar--it's a mildly novel flow control construct for structured programming. Certainly Python doesn't have anything like it right now; "while True:" isn't an exact match (and "while False:" is equivalent to "if 0:"). My "do:" would allow spelling do/while as:

do: something() if condition: continue

I think that's a reasonable do/while, and so economical: we only added one new keyword. This form of "do:" has other uses too, as per my previous email.

Not that I expect this syntax to take the world by storm.

It's funny because I had something like this in mind when I myself suggested 'break if ...' and 'continue if ...' a little while ago (although I would go for a 'loop:' that doesn't need to be continue'd explicitely). I had come to the point of view that the restrictions of the looping construct had in fact somehow liberated it and made it more versatile by making

if condition: break

and

if condition: continue

common control flow constructs inside a while loop, that in particular encompass the do ... while / repeat ... until constructs, etc seen in other languages (I may have expressed myself better in the original thread). My motivation for 'break/continue if ...' was that it would make those constructs stand out more (and could be hilighted clearly as such in editors) - I was a bit surprised when I was told it would make code less readable and that it was a slippery slope, but then I have lots of ideas, most of which don't turn out to be very good :)

I think it would help it to stand out. while 1: ... if a == 2: b = finished if b == 3: breakit() if c == 4: break if d == 5: baker = name if e == 6: steak = done while 1: ... if a == 2: b = finished if b == 3: breakit() break if c == 4 if d == 5: baker = name if e == 6: steak = done Ron

On 27 Apr 2009, at 18:49, Terry Reedy wrote:

A quick summary of my views:

1. When I programmed in C, I hardly if ever used do...while. I have read that this is true of other C coders also. So I see no need for a Python equivalent.

I haven't got much C that I wrote myself, but on my most recent C project, out of 100 loops: * 65 are while loops * 31 are for loops * 4 are do-while loops In the py3k C source, out of 100 loops I see: * 60 for loops * 32 while loops * 8 do-while loops

2. On the other hand, loop and a half use is a regular occurrence. Anything that does not arguably improve

while True: part1() if cond: break part2()

such as

loop part1() whhile not cond: part2()

seems pretty useless. But even the above does not work great for multiple "if... break"s and not at all for "if...continue".

This is my opinion also.

3. I do not see 'if cond: break' as that much of a problem. One can emphasize with extra whitespace indent or comment. if cond: break #EXIT#

In any case, I see it as analogous to early return

def f(): part1() if cond: return part2()

and while there are purists who object to *that*, I have not seen any proposals to officially support better emphasis (other than the existing whitespace or comment mechanisms).

My idea with 'break/continue if' was, in my mind, such a proposal. I thought that it would enshrine what I perceived as a very common construct ('if ...: break/continue') into the language and make it easier to spot when scanning code.

In fact, it is not uncomment to use 'return expr' instead of 'ret=expr; break' when a loop (for or while) is the last part of a def.

4. "do ... while cond:" strikes me as ugly. Aside from that, I do not like and would not use anything that puts the condition out of place, other than where it is executed. I would hate to read such code and expect it would confuse many others.

I definitely agree with this. -- Arnaud

Terry Reedy wrote:

A quick summary of my views:

1. When I programmed in C, I hardly if ever used do...while. I have read that this is true of other C coders also. So I see no need for a Python equivalent.

2. On the other hand, loop and a half use is a regular occurrence. Anything that does not arguably improve

while True: part1() if cond: break part2()

such as

loop part1() whhile not cond: part2()

seems pretty useless. But even the above does not work great for multiple "if... break"s and not at all for "if...continue".

I agree. I don't see lack of do--while as a wart.

3. I do not see 'if cond: break' as that much of a problem. One can emphasize with extra whitespace indent or comment. if cond: break #EXIT#

In any case, I see it as analogous to early return

def f(): part1() if cond: return part2()

and while there are purists who object to *that*, I have not seen any proposals to officially support better emphasis (other than the existing whitespace or comment mechanisms).

In fact, it is not uncomment to use 'return expr' instead of 'ret=expr; break' when a loop (for or while) is the last part of a def.

The 'break if'/'continue if' would make the break and continue more visible in some cases, but I now realize it also is limited to a single line rather than a block. ... if exit_cond: ... ... break ... Break and continue are pretty visible as long as they are on a line by themselves, so maybe we should just stick with what we have.

4. "do ... while cond:" strikes me as ugly. Aside from that, I do not like and would not use anything that puts the condition out of place, other than where it is executed. I would hate to read such code and expect it would confuse many others.

I agree.

5. We well never reach consensus. PEP 315 might as well be withdrawn.

Unless there is some very nice examples or performance reasons to show otherwise, I just don't see enough need to be a convincing change. Ron