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