PEP 315: Enhanced While Loop

Steven Taschuk staschuk at telusplanet.net
Sat May 3 13:07:04 EDT 2003


Quoth W Isaac Carroll:
> PEP: 315
> Title: Enhanced While Loop

Excellent!  Whatever the outcome, this frequent request certainly
deserves a PEP.

  [...]
> Syntax
> 
>      The syntax of the while statement
> 
>          while_stmt : "while" expression ":" suite
>                       ["else" ":" suite]
> 
>      is extended as follows:
> 
>          while_stmt : ["do" ":" suite]
>                       "while" expression ":" suite
>                       ["else" ":" suite]

Consider this code:

    do:
        foo()
    while bar():
        snee()
    while quux():
        fnord()

How many loops is that?  According to the syntax above, it's two.
But I think some readers might expect it to be one, like this:

    while 1:
        foo()
        if not bar():
            break
        snee()
        if not quux():
            break
        fnord()

Of course, if the syntax were extended to allow multiple while
clauses, so that this latter interpretation became correct, then
there would arise the problem of what to do when you *did* want
two loops.  You'd have to add a pass statement:

    do:
        foo()
    while bar():
        snee()
    pass
    while quux():
        fnord()

(Or "else: pass" or "do: pass" in the same place, for example.)

This is not appealing, so we return to the original, where each do
has exactly one while, and there is possible confusion about the
associations of subsequent whiles.

This confusion can arise because in the proposed syntax, we have a
keyword -- while -- which can occur both to introduce the first
clause of a statement, and to introduce the last clause of a
multiclause statement.  No other keyword has this property.

For another example of why this is undesirable: suppose you have a
file open in your text editor and the first line on the screen
starts with while.  Is there more to the loop off the top of the
screen?  You don't know.  Again, no other clause-starting keyword
leaves you in doubt: as things stand now, if, while, for, def, and
class always start statements, and elif, else, except, and finally
always continue them.

This argument suggests that we should use something other than
'while' here.   Suppose, for example, that we use 'break if' (and
reverse the meaning of the condition).  Then we have

    do:
        foo()
    break if not bar():
        snee()
    break if not quux():
        fnord()

This does away with the ambiguities, and gets us multiple
breakouts pretty much for free.

The reader no doubt anticipates my next step, which is to wonder
why we're introducing a new keyword, 'do'.  Why not:

    while:
        foo()
    break if not bar():
        snee()
    break if not quux():
        fnord()

In this version the syntactic sugar is particularly transparent.
I do not see that this is appreciably clearer than the presently
idiomatic form, with if ...: break.  The alignment of the breaks
with the while is kind of neat, but imho it's not worth changing
the language.

-- 
Steven Taschuk                           staschuk at telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks





More information about the Python-list mailing list