[Python-ideas] Updating PEP 315: do-while loops

Ron Adam rrr at ronadam.com
Tue Apr 28 08:58:50 CEST 2009



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



More information about the Python-ideas mailing list