PEP: statements in control structures (Re: Conditional Expressions don't solve the problem)

Carl Banks idot at
Thu Oct 18 22:39:42 CEST 2001

Huaiyu Zhu <huaiyu at> wrote:
>                 PEP: Statements in Control Structures

The problem I have with this proposal (besides the sheer ugliness of
the syntax) is that there is an assumption made that there are at most
a few statements required before the exit test.  This is not always

For example, I have written loops like this before:

    while 1:
        <lots and lots of statements>
        if <condition>:
	<maybe a few other statements>

With your proposal, all those lots and lots of statements would have
to be chained into one logical line of code.  Of course, no one is
going to do that, so in such cases we would revert to the old 
"while 1:" idiom.  We're right back to where we started.

Now, I have no problem whatsoever with the "while 1:" idiom.  But the
point I'm trying to make is this: if we *must* add new syntax to the
language, let's not go with a partial solution to the "problem",
especially when that solution is ugly and unPythonic.

The Python-like way to organize statments is to put them in blocks,

>             if stmts1; expr1:
>                 stmts2
>             elif stmts3; expr2:
>                 stmts4
>             elif stmts5; expr3:
>                 stmts6
>             else:
>                 stmts7

I would suggest something more along these line (fleshing out the
example a little):

        m = (somthing)
    if m:
        do_something_with (m)
        m = (somthing_else)
    if m:
        do_something_else_with (m)
        raise some_exception;

I hope it's obvious how it works.  Once we've met a condition and
entered an if block, we will make no more suppositions (i.e., further
elsuppose blocks would not be executed).  Of course, the suppostions
could involve more complex calculations than regexp searching, which
would make the statements-in-control-structures approach unweildy.

>             while stmts1; expr1:
>                 stmts2
>                 if expr2: break
>                 stmts3
>             else:
>                 stmts4

I would suggest something like:

    while <condition>:

with the do part optional.  The exact keywords and semantics I don't
care about.  But, like I said, I have no problem with "while 1:".

>     3.2. Better break-else interaction:
>         Python allows an else-clause for the while statement.  The naive way
>         of writing the general loop-and-half in current Python interferes
>         with the else clause.  For example,
>             while x = next(); not x.is_end:
>                 y = process(x)
>                 if y.is_what_we_are_looking_for(): break
>             else:
>                 raise "not found"
>         cannot be written in this naive version:
>             while 1:
>                 x = next()
>                 if x.is_end: break
>                 y = process(x)
>                 if y.is_what_we_are_looking_for(): break
>             else:
>                 raise "not found"

I completely disagree with this rationale.  The only thing naive about
this example is your suggestion that an else clause would be useful
here.  You should know that the raise statement belongs after
"if x.is_end:".

Generally speaking, when performing a test, you want to be able to
specify code to execute for either result, true or false.  With an if
statement, you can do this, obviously.  In most languages, you cannot
specify code to execute when a test by the while statement results in
false.  However, you can in Python, which is why else clauses on while
statements are so cool.

But, when an if statement tests your exit condition, as in the "while
1:" idiom, you already have all the flexibility you need.  There is
nothing an else clause following the while statement can add to it.

All-in-all, I don't feel there is much reason to change the language
for this.  The suppose statement might be nice to occasionally avoid
deeply nested ifs, but I can live without it.


More information about the Python-list mailing list