PEP 315: Enhanced While Loop

[Beni Cherniavsky]

Michael Chermside wrote on 2003-05-05:

> > [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>
>
I agree that ``loop:`` is better than ``while 1:`` and ``while True:``
(I must admit that while I like `True`/`False`, I still prefer the
``1`` since a number visually stands out better and it looks more
"syntetic").  However I'd perhaps prefer ``while:`` over ``loop:`` for
the ``and while`` proposals.  Make clear that this part of the PEP is
optional.

> 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!
>
Agreed.  Moreover, you should call the construct by its known name -
"loop-and-a-half".  AFAIK, this construct was first published in
Knuth's excellent "Structural programming with GOTO" paper (google for
it) and there he invented this name.

> Thirdly, I would suggest that you clearly address the problem
> of "dangling while" and specify how it is to be addressed.

This is fixed in the ``and while`` idea.  I'd like to suggest a few
variants.  First, the "ideal" indentation would be::

    loop:
            <suite>
        <cond>:
            <suite>

This is very alien to python's indentation style so it'd not work.

Somebody said ``and while`` sounds wrong because it seems to split it
into several loops, suggesting ``and if``.  I'd like to propose a bare
``and``::

    while:
        <suite>
    and <cond>:
        <suite>

This reads stangely if the first while has no condition, so perhaps
even the ``and`` should be omitted (*Parsing danger*, Will Robinson).
As a radical option, consider this::

    while
        <suite>
    <cond>:
        <suite>

This reads nicely as "a while whose condition was moved into the
middle of the loop :-).  Yes, I know Guido will not accept this.

> Lastly, I would suggest that you _define_ the behavior of
> the new construct in terms of existing syntax. Guido likes
> that...

Basically good idea.

>[snip]
> 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:
>     [snip]
>      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.
>
If *that's* how you'll define it, I think it's a bad idea.  At this
stage, IMHO it's best to just give the whole new definition of
``while``.

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

> 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.
>
There is a trivial test that nobody seems to have done yet:

$ cd Python-2.3b1/Lib
$ find -name '*.py' | xargs cat | grep -c $'^[ \t]*while .*:'
730
$ find -name '*.py' | xargs cat | grep -c $'^[ \t]*while 1:'
220
$ find -name '*.py' | xargs cat | grep -c $'^[ \t]*while True:'
50

WOW!  That means that about *every third* while loop in the standard
library is an "infinite" loop!  I'm sure each of them has a break.  I
can't easily check how many have simple post-conditions ("do until")
but in my experience, checking at the end is less useful than at the
middle.  These statistics convince me that this PEP is definitely not
YAGNI.

The other notable thing is that there are only ~730 while loops in the
whole standard library (a little more, the ``.*:`` misses multi-line
conditions).  The simple truth is that ``for`` is just much more
useful:

$ find -name '*.py' | xargs cat | grep -c $'^[ \t]*for .* in .*:'
2683

As expected ;-)

-- 
Beni Cherniavsky <cben at users.sf.net>

"Intercept course punched in." -- from a sci-fi movie, happening
centuries from now.  So don't forget your puch-card skills yet!