why no "do : until"?

[Alex Martelli]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3A541290.DBC66A99 at engcorp.com...
> Alex Martelli wrote:
> >
> > "Peter Hansen" <peter at engcorp.com> wrote:
> >     [snip]
> > > I can see your point (remarkable, given this thread, isn't it? :-).  I
> > > guess I consider the "block" to be everything except the code that
allows
> > > entry into the block.
> >
> > 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.

> 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.

Similarly, in the loop's case, assuming no exceptions occur, all
statements in suite1 execute; but the statements in suite2 are
then a different 'block', as it doesn't require any exception to
inhibit their execution.

> (Don't bother taking that definition too literally.  I understand
> the possibly of a return in the middle of the code, etc.  It's the
> spirit of this definition I want to communicate, not the letter. :)

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.


> These two blocks are effectively just 'sub-blocks' of whatever block
> of code contains the whole 'try/except' statement, which may or
> may not have preceeding and following statements.
>
> So no, I most definitely would have trouble if the 'except' statement
> were to be indented, since it is _not_ part of the <suite1> block
> in the 'try' portion of the code.

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
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.


> The graphical examination of the three brace/indentation styles in
> Code Complete by McCarthy is, in my opinion, an excellent way of
> comparing the alternatives.  I can't imagine anyone feeling
> wholly comfortable with the traditional K&R style after reading
> that section.

I've often been considered 'unimaginable', albeit for different
kinds of reasons, but let me assure you that I'm perfectly familiar
with McCarthy (and many, MANY other style books:-) and still
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 was extremely happy to discover, in my first
> moments looking at Python code, that the indentation-based
> syntax of Python exactly maps to the style I've used for so long
> and which McCarthy argues is superior.

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...!-)


Alex