while 1:
      line = fp.readline()
      if not line: break
      print line

In a language which is touted as being so clear, I'm kind of surprised that
this hasn't received more attention.

It would seem that one could set up a variable or possibly a set of variables
which would contain the value of the expression in the last executed
conditional:

   while fp.readline():
      if re.match(whileVar, r'^\s*(\S+)\s*=\s*(\S+)\s*$'):
         print 'Assignment "%s" = "%s"' % ( ifVar.group(1), ifVar.group(2) )

This has the benefit of allowing you to easily see the termination condition
for the while loop, instead of assuming it's infinite until you search
through (the possibly complex) body.

This would seem to eliminate the required kludge, while still keeping with the
basic spirit of Python.  However, before going through and making a patch for
Python, I wanted to see what comments folks had on this idea.

The next logical step I could see would be adding a variant to conditionals:

   while [ <word> = ] <expression>:

where if the optional [ <word> = ] part of the while statement were there it
would assign the expression value to <word> in addition to the whileVar.  But
then what would be the point of having the whileVar?

Is the only concern that this will be confused with the "==" comparison
operator?  In that case, would "while [ <word> assign_the_value_of ]
<expression>:" (or something similar) be more appropriate?  Or perhaps
even something along the lines of "<word> = while <expression>:"?
That feels a bit strange, but surely won't be mistaken for a comparator...

The only issue I see with this is the scope of the "whileVar".  Presumably
one could limit the scope by doing a "whileVar = None", or perhaps the
termination of a while would imply that?

Maybe something should go to the FAQ.

    import fileinput
    for line in fileinput.input():
        process(line)

It doesn't read the whole bunch but behaves like a sequence
and enumerates all the input lines by its __getitem__ method.

If you think you must, here is also a minimal example
how to wrap an assignment by a small class.

class remember:
    def __init__(self, func):
        self.func = func
    def __call__(self):
        self.line = self.func()
        return self.line

myline = remember(open('c:\\autoexec.bat').readline)
while myline():
    print myline.line

All in all it is no big deal and not necessary.

cao - chris

I've done more than my share of supplying stupid "workarounds", so I guess I
deserve that.  In real life I always use the "kludge" you listed above.

    while 1:

I assume the opposite:  that it's a finite loop and I'll find an "if ...:
break" one or two lines down.  I'm rarely disappointed <wink>.

Believe it or not, I *do* sympathize with your complaint -- while I'm used
to it now, I've never *liked* writing "while 1:" (for the very reasons you
state), and think it would be peachy to peel the conditional banana.

    while (x = f()) { ... }

by mistake when

    while (x == f()) { ... }

was intended.  God knows, just last week I tracked down what turned out to
be a

    assert(n = 1);

bug in C++ (that assert is a self-fulfilling prophecy <snarl>).

Every post-C language except the no-choice-in-the-matter C++, and Perl (&
now Ruby too, alas), has moved heaven and earth to avoid propagating this
miserable design error.

    while x := f():

i.e. use the currently-unused ":=" to mean binding-as-expression.

    while (sum := (x := f()) + (y := g()) + (z := h())) < (lim := i()):
        print "sum", sum, "<", lim, "prod", x*y*z

But I think the best way to encourage clean code is to ridicule newbie code
postied to c.l.py <wink>.

All of those irksome questions (& many more) are sidestepped cleanly by
letting the user bind their own vars explicitly when & as they feel they
need to.

do:
    line = fp.readline()
while not line

  This is one of my few problems with the language, and though I've
gotten used to writing 'while 1'...'if something: break', it still
gives me a twinge of annoyance every time I do it.

(Aside: didn't someone suggest generalizing do...while once by
allowing conditions inside the block?  Can't pull it up in Dejanews,
though.)

do:
    line = fp.readline()
    if line:
        code goes here
        code goes here
        code goes here
while not line

to do the same thing, and that's no improvement over

while 1:
    line = fp.readline()
    if not line:
        break
    code goes here
    code goes here
    code goes here

Or does the condition on the "while" magically get evaluated right after the
first stmt following the "do" is executed <wink/shiver>?

    Proposal: do-while-(do)  (was [Q] Perl vs. Python)

from late June.  I still recommend that people read Knuth's classic
"Structured Programming with Gotos" for a slew of creative approaches.

Assignment-as-expression is good for more than just exit-at-the-top loops,
though.  It can be genuinely helpful whenever a function may return a
special-case value.  Most frequently this year, I've dutifully replied to
msg after msg griping about:

    m = re.search(re1, line)
    if m:
         xxx(m)
    else:
        m = re.search(re2, line)
        if m:
            yyy(m)
        else:
            m = re.search(e3, line)
            if m:
               zzz(m)
            else:
               poop()

etc.  There are other ways to write this, but I twinge too at trotting them
out because there's really no way as simple or clear as the obvious thing
the complainer *wants* to do:

    if m := re.search(re1, line):
        xxx(m)
    elif m := re.search(re2, line):
        yyy(m)
    elif m := re.search(re3, line):
        zzz(m)
    else:
        poop()

I'd trade the reduction in artificial nesting (or clever convolution to
avoid it some other way) for the chance that some dribbler will abuse it:

def fac(n):
    a=long(n or 1)
    while(n:=n-1)>1 and a:=a*n:pass
    return a

I'm a bit tired -- sorry if I ramble on a bit :)

  while 1:
     ...some code...
     if not condition: break
     ...more code...

? Actually I think this is clearer (although not as "pretty"). I
usually relate these control structures to natural language... This
latter thing means:

  Until I tell you otherwise:
     Do something
     If some condition: Stop everything
     Do something more

The thing above might be stated as:

  Do something while some condition is true do something else.

What does that mean? It's not even a proper sentence...

Oh well...

do:
  line = fp.readline()
  print line
while line

is the same as

line = fp.readline()
while line:
  print line
  line = fp.readline()

Now this seems pretty clear to me. And if we wanted to have the
functionality of the do--while loop without sacrificing standard
Python syntax, how about using repeat--until without the "repeat"?

until not line:
  line = fp.readline()
  print line

(This executes the body once before checking the condition)

Or maybe it should be possible to do something like...

while line=fp.readline(); line:
  print line

My professor Arne Halaas published an article on another control
structure in 1975, which is quite general. He called it "detect". It
works like this:

  DETECT <event1> OR <event2> OR ... OR <eventn>
         IN
         ...
         NI

The events can be either constants or event-variables given some value
(I'm not quite clear on their function... ;)

The event constants are used in the loop like this:

  <event3> {some code};

Thus if the event is detected by the surrounding DETECT-block, the
code in the {} part is executed and execution is resumed after the NI
part of the DETECT-block. Several events could be used, like in

  <event1> OR <event2> {some code};

These indicator statements may be mixed with ordinary code (sorta like
break statements). In his article, Halaas uses the example of the
Quicksort Partition algorithm using what might be seen as two
coroutines moving element up and down:
(Array elements A(m)..A(n) are to be partitioned)

  i := m-1; j := n;
  v := A(n);
  DETECT partition done
         IN
         DETECT downmovej
                IN
                i := i+1;
                IF i=j THEN partition done;
                IF A(i)>v THEN downmovej {A(j):=A(i);};
                NI
         DETECT upmovei
                IN
                j := j-1;
                IF j=i THEN partition done;
                IF A(j)<v THEN upmovei {A(i):=A(j);};
                NI
         NI
  A(j):= v

A suitable Python syntax for this sort of thing might be (I'm changing
it a bit here, I guess -- removing the {}-part, making it necessary to
use if-statements. I think that would be clearer in Python...):

  i = m-1
  j = n
  v = A[n]

  detect "Partition_done":

      detect "Move j down":
          i = i+1
          if i==j: break "Partition done"
          if A[i] < v:
              A[j] = A[i]
              break "Move j down"

      detect "Move i up":
          j = j-1
          if j==i: break "Partition done"
          if A[j] < v:
              A[i] = A[j]
              break "Move i up"

  A[j] = v

This looks quite like labelled breaks, I guess... (The use of strings
in the above is arbitrary -- one might easily have a separate label
type or something...)

One advantage of the detect structure (as Halaas points out) is that
the events may be used to make the code document itself quite nicely.
You clearly see why things are happening.

Now -- back to the original problem...

  detect "End of file":
      line = fp.readline()
      if not line: break "End of line"
      print line

I kind of like this approach (though I'm sure my syntax suggestions
leave a lot to be desired). In the simple example above, the labels
may not be very useful, but the partition example shows how they may
be. Anyway, even in this simple example, I think the mechanism looks
prettier than arbitrarily looping forever, and then later breaking
out... At least here you show what you are waiting for.

And if we *must* use the endless looping solution (without any labels)
can't we *please* have a separate keyword like "loop"? "while 1" seems
so arbitrary...

  loop:
    line = fp.readline()
    if not line: break
    print line

That isn't so bad, is it? (Of course it can't be nested -- but the
"detect" structure can...)

And lastly: Any errors or shortcomings in the detect-presentation
above are mine alone.

--

    while "fp has more stuff":
        line = fp.readline()
        if not line:
            break
        process(line)

This is a bit slower than "while 1:" today, but nothing a peephole optimizer
couldn't safely squash out of existence.

Similarly in C or C++ it's often better to write

    assert(!"wow -- unto the root is born a brother!");

than

    assert(0);