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

[Stephen J. Turnbull]

spir writes:

 > do:
 >    <suite>
 > until <condition>
 > 
 > (or any footer variant) the header "do:" warns you about the loop's
 > logic: loop at least once, then check for an exit condition --
 > logically written at the loop's exit point ;-)
 > 
 > If the real issue you have in mind is that the loop's body may not
 > fit inside the editor window, well...

Not for me.  The real issue is that people think top-down, which has a
double meaning.  First, we write sequences of statements from
top-to-bottom on the page, and read them the same way.  Second, we
construct applications by starting with a high-level abstraction, and
gradually add complexity by implementing lower and lower level
functionality.[1]

Note that C, and many other languages, implement some kind of include
functionality in large part to allow you to declare many identifiers
*early* but without interfering with the correspondence of top-down
*reading habits* to top-down *design*.

So as I'm reading down the page, it's natural for the structured
concept (high level decision of what to do) to be above the detailed
implementation (lower level decisions about how to do it).  Having the
complete condition available at the top of a structure is something
I've always wanted from do ... while or repeat ... until (but didn't
know that until Raymond pointed it out<wink>), because it's not enough
to know that this is a structure.  Rather, having the condition
available tells me (in many cases) whether this is a normally-once,
occasionally many, "retry" kind of function, or a typically
multi-iteration task that just happens to need to always be done at
least once.  That often affects my perception of the code enough to
demand rereading if the condition is of the "wrong" kind based on my
prior expectation.

YMMV of course.

Footnotes: 
[1]  Yes, I'm aware that time-and-motion studies of programmers show
that few programmers actually write programs that way.  In fact most
programmers, including excellent ones, switch back and forth between
top-down, bottom-up, and other modes (inside-out?).  What's important
is that in many cases it makes it much easier to read and understand
somebody else's program.