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