PEP 315: Enhanced While Loop

[Michael Chermside]

> [W Isaac Carroll posted PEP 315 (revision 1.1)]

Isaac:

Thanks for the excellently written PEP! There are three minor
changes that I would propose. First, incorporate Alex's 
suggestion of "loop" instead of "do" for the introductory 
keyword:

    loop:
        <loop code>
    while condition:
        <more loop code>

which is (IMHO) quite readable. Secondly, I would suggest
re-ordering the motivation section to stress the particular
existing-syntax-alternative which is most strongly supported
by python experts and PEP opponents. They tend to prefer the
synatx of:

    while True:
        <loop code>
        if not condition: break
        <more loop code>

so I would list that alternative first, or perhaps just
indicate in the discussion that it's the syntax preferred by
many in the absense of the PEP. Of course, you should KEEP
the comments about why this solution is not desirable...
after all, this is the MOTIVATION section!

Thirdly, I would suggest that you clearly address the problem
of "dangling while" and specify how it is to be addressed.
Give a specific example like this:

    count1 = count2 = 3
    loop:
        print "A"
    while cond1:
        cond1 -= 1
        print "B"
    while cond2:
        cond2 -= 1
        print "C"

and tell what the output would be. (My proposal would be 
"ABABABACCC", but go with whatever solution you like so
long as it's unambiguous.)

Lastly, I would suggest that you _define_ the behavior of 
the new construct in terms of existing syntax. Guido likes 
that... in fact, in the case of list comprehensions he left 
what I would consider a wart (leaving the loop variable 
around after completing the comprehension) in order to 
exactly conform to the definition he had used). I would 
suggest something like this:

     The behavior of this construct:
     >>> loop:
     ...     <suite 1>
     ... while <condition>:
     ...     <suite 2>
     
     will be exactly the same as the behavior of
     >>> while True:
     >>>    <suite 1>
     >>>    if not <condition>: break
     >>>    <suite 2>

but you'll have to be very careful about handling all
situations including "else" clauses... so I'd probably
add that:

     The behavior when an "else" clause is present:
     >>> loop:
     ...     <suite 1>
     ... while <condition>:
     ...     <suite 2>
     ... else:
     ...     <suite 3>

     will be exactly the same as the behavior of

     >>> __normal_loop_exit__ = False
     >>> while True:
     ...    <suite 1>
     ...    if not <condition>:
     ...        __normal_loop_exit = True
     ...        break
     ...    <suite 2>
     >>> if __normal_loop_exit__:
     ...    <suite 3>
     >>> del __normal_loop_exit__

     *except* for the fact that the variable 
     "__normal_loop_exit__" will not be visible in any
     scope.

Kinda excessive detail for a behavior that's obvious, but
the PEP should spell it out.

Anyway, nice work on this PEP... it's something we've needed
for a long time.


Now for the bad news. I'm -1 on this PEP. I think it should
be rejected, for two reasons: I think the alternative *IS*
sufficiently readable (reasonable people could disagree, but
that's my opinion) and I find newbies tend to write better
code (fewer errors) if they are forced to do their tests at
the top of the loop (which is where the tests belong for the
overwelming majority of loops).

But enough of *MY* reasons... this is a FREQUENT request, and
it deserves a good writeup and evenhanded consideration. If
it's accepted, we'll have a new language feature (and it should
be as well-designed as possible). If it is rejected, at least
what got considered was the very BEST syntax possible.

-- Michael Chermside