why no "do : until"?

[Andrew Henshaw]

Steve,

Forgive me for not knowing your stance on some of the earlier points
discussed, but I was responding to Rober Amesz' do - until proposal.  Would
not your statements also apply to his use of
    until condition
instead of
    if condition: break
?
I suppose that you could limit each 'do:' loop to one 'until' to avoid the
multiple breaks problem.  Implicit in that proposal would be the assumption
that 'if condition: break' would not be allowed in a 'do:' loop.  I don't
think that suggestion would fly very well.

Given Python's current structure, I still believe that the best compromise
is the allowance of
    do:
as a synonym for
    while 1:

and leave it at that.


AH

"Steve Williams" <sandj.williams at gte.net> wrote in message
news:3A5F264D.4D7C024A at gte.net...
> Andrew Henshaw wrote:
>
> > "D-Man" <dsh8290 at rit.edu> wrote in message
> > news:mailman.979261813.31482.python-list at python.org...
> > > On Fri, Jan 12, 2001 at 12:33:58AM +0000, Robert Amesz wrote:
> > > [snip]
> > ...snip
> > [more snip]
>
> >
> > Python's existing 'if condition: break', with its colon, stands out and,
> > more clearly than the 'until', shows its true function; which is,
> > essentially, a goto past 'something else' and out of the loop.  I
believe
> > that support for this is more likely than for the other more significant
> > changes.
> >
>
> If you have nested 'do' statements, you have to keep track of the nesting
> structure to find a break target.  Searching for the first 'break' after a
'do'
> may or may not find the loop invariant.
>
> Similarly, if you have multiple 'breaks' for a single 'do', the first one
you
> find may not be the one that bit you.
>
> With 'break', the program flow no longer corresponds to the program
listing
> (the original complaint about g*t*, IIRC).
>
> There will always be debugging questions such as "how did I get here?" and
"why
> did I skip this?" in procedural languages.  'Break' adds a little extra
> excitement to these questions.
>
>