why no "do : until"?

[Peter Hansen]

Alex Martelli wrote:
> 
> "Peter Hansen" <peter at engcorp.com> wrote:
> > Alex Martelli wrote:
> > >
> > > So what about:
> > >     try:
> > >         <suite1>
> > >     except something:
> > >         <suite2>
> > > and so on?  Would you like it better if the 'except' was indented?  It's
> > > NOT, after all, 'code that allows entry' in the "block" (overall try/except
> > > statement).
> >
> > I _do_ consider it to be 'code that allows entry' into the block.  After
> > all, there are _two_ blocks here, nested inside a single outer block:
> >
> > try:
> >     block1
> > except:
> >     block2
> 
> And what is the alleged difference with:
> 
>     while <condition1>:
>         <suite1>
>         if <condition2>: break
>         <suite2>
> 
> ???  Here, too, we have two 'blocks' (suites), nested into a single
> loop.

I may be changing my claimed definition of a block, but not what
I meant in the first place... try this: "a block is a sequence of
statements all at the same (indentation) level, uninterrupted by 
statements of a higher level."

In other words, the 'try/except' consists of one outer block with
a single 'compound' statement which contains within it two "subblocks"
(nested blocks at a lower indentation level).

The while/if/break consists of a total of three blocks: the outer
one containing only the 'while' statement, the contained block which
is always present after a while statement, and the even-lower-level
block that is nested under the 'if' statement.  In other words,
I consider <suite1>, the 'if', and the <suite2> statements all 
to be part of the same block (since they're at the same 'level'), 
which is the single block that contains the code within a 'while' 
statement.

(Peter wrote:)
> > To me, a block is a set of statements which are indivisibly executed
> > when unexceptional operation occurs (within the block).  That is,
> > assuming no exceptions occur, all statements within block1 execute.
> > After a possible exception occurs, all statements in block2 execute.

Yes, I definitely wrote a poor description of what was in my mind.
Scratch the immediately above paragraph entirely.

(Alex wrote:)
> But 'the devil is in the details'!  A 'basic block' as normally
> considered by a compiler *does* need to consider conditional
> breaks, continues, returns as terminating the block.

Then clearly the definition of 'block' in the context of compilers
is unrelated to the definition of 'block' in my mind and in my
indentation style in C.

> I still fail to see how you conceptualize a while/if...break as so
> drastically different from an if/else, try/except, and so on.  I see

I'm sorry, I didn't mean to state that the two were in any way 
different, and I don't believe they are.  'if/else' consists of three
blocks (two nested ones inside an outer one).  The
'try/except' is identical.  The 'while/if/break' is as I described
above. 

> it as just syntax sugar, determined by historical accident, for
> Knuth's loop/while statement:
>     loop <condition1>:
>         <suite1>
>     while <condition2>:
>         <suite2>
> and consider the Python-enforced indentation of its spelling of
> 'while <condition2>:' (which is "if not <condition2>: break":-)
> to be a minor annoyance.

To tell you the truth, I hadn't examined the above structure in
detail before now.  If it is really intended to be identical
to the 'while/if/break' structure, then I have to say I think it's
really, really ugly, at least when written the way you have above.
To me the entire content of the 'loop' statement would have to
be considered a _single_ block, which to me would require the
indentation of the 'while <condition2>' part to be indented
along with everything else.  Only 'loop' could be outdented.

Without spending more time examining Knuth's structure and
figuring out the implications, I can only say I'm very happy
with 'while/if/break' in general, and especially in comparison
to the Knuth alternative.  I have no idea whether this makes
my technique completely inconsistent in the face of this
theoretical structure, but I find the outdented 'while'
in the above completely violates my ideas of propriety! :)

> ... let me assure you that I'm perfectly familiar
> with McCarthy (and many, MANY other style books:-) ...

(My bad: someone else mentioned Steve McConnell and it
was in fact he, not Jim McCarthy, who wrote Code Complete.)

> consider KR style by far the best.  Screen real-estate (most
> specifically, number of lines displayed at once) is an important
> resource to be invested wisely, not squandered...

I can understand that argument, but years ago I concluded 
the tradeoff I was making to follow K&R was not worth it.
I believe even with braces taking up individual lines all 
by themselves, I have more than enough lines on-screen at once.
If I feel I can't see enough code with the 35 or 50 lines I
have in the window, I conclude my code is likely getting
too complex and needs refactoring.  Meanwhile the extreme
cleanliness of my brace indentation style makes the 
refactoring proceed more reliably and easily.  But YMMV, and
obviously does.  :)

> And I was just as happy to discover that Python's use of
> indentation in lieu of braces completely avoids squandering
> precious screen-lines unproductively -- just like (even better,
> actually) the K & R style which I'll always keep using and
> defending for C, C++, and Java sources.
> 
> Isn't Python just great in its ability to keep happy people
> from such opposed camps, through the SAME device?-)  Worth all
> the interminable threads on this group with non-Pythonistas who
> are *adamant* Python *SHOULD* allow (or mandate) braces...!-)

Complete, total agreement!  :)