Thoughts on PEP315

[Stephen Horne]

On Tue, 23 Sep 2003 21:59:15 -0400, Gordon Airport <uce at ftc.gov>
wrote:

>The point of do-while loops is that you don't need setup code anymore, 
>right? How about this:
>
>...
>dowhile <condition>:
>	<loop body>
>...
>
>where the body is run once before it becomes a standard while loop. It 
>looks like we all think of this structure as a "do-while loop", so the 
>expression is natural. This also makes it easy to change loop types - 
>just add or remove the "do". Slight downside is that the execution flow 
>isn't exactly as you read it.

This doesn't really solve the problem that the PEP aims to solve.

The setup code in the following example (from the PEP) is only *part*
of the code in the loop...

 do:
   <setup code>
 while <condition> :
   <loop body>

The condition is tested in the middle.

The precondition form duplicates the setup - this is what the PEP was
trying to avoid...

 <setup code>
 while <condition> :
   <loop body>
   <setup code>

But the postcondition-compliant form is really no better...

 do :
   <setup code>
   if <condition> :
     <loop body>
 until !<condition> :

(or if you insist)

 dowhile <condition> :
   <setup code>
   if <condition> :
     <loop body>

You're simply duplicating the condition instead of the setup code. As
loop conditions are often at least as complex as the setup code, there
is really no gain here.

In addition, the 'if' isn't explicitly a loop exit point - it's just a
nested structure that achieves the same effect - so it doesn't express
as clearly the intention behind the code.

The whole point of the syntax in the PEP is to have the loop condition
tested in the middle of the loop - something which in C (and current
Python) is handled badly by the unstructured 'break'.


Secondly, what the PEP suggests is not what most people think of as a
'do-while' loop. Anyone sufficiently familiar with C, C++, Java, ...
will see a 'do-while' loop as being postconditioned (much like
repeat-until in Pascal etc) - ie not having the loop condition tested
in the middle as the PEP proposes.


Finally, IMO execution order should match reading order unless there
is a *VERY* good reason to do differently.

Pascal, C and even Basic manage to show a precondition at the start of
a loop, but a postcondition at the end of a loop. I don't see any good
reason why Python can't follow suit.


IMO, a loop exit point should... (highest priority first)

  1.  Be written at the point where the condition is tested, such that
      execution order is the same as reading order.

      I don't want to see variables referenced in a condition that
      haven't even been defined yet, for instance. You see this as
      minor - I see it as *very* important.

  2.  To be clearly identifiable be its leading keyword(s), and in
      particular not be confusable with the start of a new structure.

      This is a problem with the C 'do ... while' - it isn't always
      clear that the 'while' is part of the 'do' loop rather than the
      start of a new 'while' loop. IMO we don't need this hassle in
      Python.

  3.  Be linked to the loop itself, much as 'else' is linked to 'if',
      by having the same indent level and the ':' marker at the end of
      the line.

      This is IMO relatively minor - I don't object that much to the
      existing 'if condition : break' - but I believe it is important
      to the PEP authors logic.


Basically, readability and maintainability are key obsessions of mine
(and pretty much anyone who has had to read and maintain large systems
written by other people).

I'm not really sure why people don't like 'break if' - but then of
course I don't, it is my invention ;-)

Maybe it's to do with the return to the indent level of the earlier
'while' - but then 'elif' and 'else' already do this in 'if' blocks.

More likely it is that bit in point 3 above - I think it is a good
idea for a loop exit point, but it isn't exactly normal practice. Adas
'exit when' is, as I mentioned, the closest match I know of.

Maybe 'break if' would end up being like a certain common reaction to
Pythons use of indentation for structuring (initial shock and disgust,
but growing to love it) or maybe I'm just wierd ;-)


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk