«

PEP 315 suggests that a statement such as

do:
x = foo()
while x != 0:
bar(x)

be equivalent to

while True:
x = foo()
if x == 0:
break
bar(x)

I like the overall idea, but wonder about the extra keyword. Moreover, if
you see

x = foo()
while x != 0:
bar(x)

you have to read backward to see whether the assignment to x is part of this
statement or part of a previous statement.

I have a proposal for an alternative syntax that solves both of these
problems:

while:
x = foo()
and while x != 0:
bar(x)

This example actually incorporates two changes:

1) "while:" is equivalent to "while True:"

2) "and while <condition>:" is an exit from the middle of the loop,
analogously to PEP 315.

My proposal allows for multiple exits in the obvious way

while <condition 1>:
<statements 1>
and while <condition 2>:
<statements 2>
and while <condition 3>:
<statements 3>
...

in which all of the conditions and statements are evaluated in the order
shown until a condition is false, at which point the loop terminates.


It also occurs to me that this notion can be generalized to include "or
while" as well as "and while". Using "or while" would implement a control
structure that Dijkstra proposed in "A Discipline of Programming". The idea
would be that

while <condition 1>:
<statements 1>
or while <condition 2>:
<statements 2>
or while <condition 3>:
<statements 3>

would be equivalent to

while True:
if <condition 1>:
<statements 1>
elif <condition 2>:
<statements 2>
elif <condition 3>:
<statements 3>:
else:
break

This notion is still partly baked, if for no other reason than that I'm not
sure how a statement with both "or while" and "and while" clauses should
work. My first thought is for "and while" to have priority over "or while",
analogously with expressions, but then the following example came to me.
It's the inner loop of a binary search:

while low < hi:
mid = (low + hi) // 2;
and while value < table[mid]:
high = mid
or while value > table[mid]
low = mid

If "and" has higher precedence than "or", this example doesn't work. So I'm
not sure about its merits -- but I'm mentioning it in case someone else can
improve on it.

"Andrew Koenig" <> writes:
> PEP 315 suggests that a statement such as
>
> do:
> x = foo()
> while x != 0:
> bar(x)

I'm still scratching my head over that PEP. Got a real-world code sample
that it would improve?

Paul Rubin wrote:

> I'm still scratching my head over that PEP. Got a real-world code
> sample
> that it would improve?

do:
line = inputFile.readline()
while line:
...
line = inputFile.readline()

--
__ Erik Max Francis && && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ The doors of Heaven and Hell are adjacent and identical.
-- Nikos Kazantzakis

Erik Max Francis wrote:

> Paul Rubin wrote:
>
> > I'm still scratching my head over that PEP. Got a real-world code
> > sample
> > that it would improve?
>
> do:
> line = inputFile.readline()
> while line:
> ...
> line = inputFile.readline()

Man, what a perfect gaffe on my part. The purpose of the do...while
construct is to _eliminate_ the duplication. This should be:

do:
line = inputFile.readline()
while line:
...

--
__ Erik Max Francis && && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ The doors of Heaven and Hell are adjacent and identical.
-- Nikos Kazantzakis

Erik Max Francis <> writes:
> do:
> line = inputFile.readline()
> while line:
> ...
> line = inputFile.readline()

So it's yet another workaround for Python's lack of assignment
expressions. I like

while (line := inputFile.readline()):
...

a lot better.

Paul Rubin wrote:

> So it's yet another workaround for Python's lack of assignment
> expressions. I like
>
> while (line := inputFile.readline()):
> ...
>
> a lot better.

(Please check my correction, it's actually not as dumb as I suggested.)

--
__ Erik Max Francis && && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ The doors of Heaven and Hell are adjacent and identical.
-- Nikos Kazantzakis

Erik Max Francis <> writes:
> Man, what a perfect gaffe on my part. The purpose of the do...while
> construct is to _eliminate_ the duplication. This should be:
>
> do:
> line = inputFile.readline()
> while line:
> ...

I still like the assignment expression better.

"Paul Rubin" <http://> wrote in message
news:...
> Erik Max Francis <> writes:
> > do:
> > line = inputFile.readline()
> > while line:
> > ...
> > line = inputFile.readline()
>
> So it's yet another workaround for Python's lack of assignment
> expressions. I like
>
> while (line := inputFile.readline()):
> ...
>
> a lot better.

It may go better in this instance, but assignment in expressions
does nothing for multi-line initialization/reinitialization constructs.

John Roth

Hell Erik,

> do:
> line = inputFile.readline()
> while line:
> ...
Just do it with generators:
for line in iter(inputFile.readline, ""):
...

Miki

"Paul Rubin" <http://> wrote in message
news:...
> Erik Max Francis <> writes:
> > do:
> > line = inputFile.readline()
> > while line:
> > ...
> > line = inputFile.readline()
>
> So it's yet another workaround for Python's lack of assignment
> expressions. I like
>
> while (line := inputFile.readline()):
> ...
>
> a lot better.

I don't, because it limits what is done before the test to a single
expression.

This PEP is really a generalization of the "while (cond) expr" and "do expr
while(cond);" statements in C. C allows the loop exit to be one expression
away from the beginning or one expression away from the end of the loop;
this PEP would allow it anywhere.