Home Original page

Conditional Expressions don't solve the problem

John Roth johnroth at ameritech.net
Wed Oct 17 13:29:22 EDT 2001 
"Kevin D" <salemail at dial.pipex.com> wrote in message
news:c2a5d721.0110170224.584a2d78 at posting.google.com...
> Guido van Rossum <guido at python.org> wrote in message
news:<cpn12riiqr.fsf at cj20424-a.reston1.va.home.com>...
> > On the other hand, the ability to hide an assignment inside an
> > expression is IMO purely a way to save some keystrokes: the variable
> > needs to be named anyway, so you may as well do the assignment in a
> > separate step so that the reader is alerted of it.
>
> But "hiding an assignment inside an expression" is just the proposed
> solution (based on the C idiom) to an identified problem. As an
> alternative to considering whether the C functionality should be
> adopted (and personally, I'm happy if it isn't) I think we should go
> back and think up a Pythonic solution to the original problem (the
> while loop thing, IIRC).
>
> As I see it, there are two basic ways to write a while loop with a
> 'load' stage, each with it's own problems:

There's a third, mentioned in a post a bit down from here. It
suggests adding a new piece of syntax: '['<statement>; ...; <expression>']'
(and I apologize in advance because this isn't really valid syntax,
but I hope you get the point.)

>
> 1) Duplication of the 'load':
>
> foo = some_long_expression
> while foo != terminating_condition:
>     body_of_loop()
>     foo = some_long_expression
>
> The argument for only having to spell the 'load' of "foo" once is the
> same as part of the argument for augmented assignment (mis-spelling of
> the expression leading to subtle bugs). This is more acute than for
> augmented assignment, as the load inside the body of the loop could be
> a great physical distance on the screen from the initial load it is
> duplicating.

It's also a case of duplication of code, which is a Bad Thing (tm).
Iterators should solve most of the cases of this thing fairly nicely.

> 2) "while 1" idiom:
>
> while 1:
>     foo = some_long_expression
>     if foo == terminating_condition:
>         break
>     body_of_loop()
>
> This solves problem (1) but IMHO, falls down in your "interrupting the
> thought process" requirement - it takes some mental juggling to work
> out just what the condition _is_ when reading the code. This is partly
> because the actual termination condition is buried somewhere away from
> the "while" statement and partly because the condition is reversed (so
> having searched out the termination condition, you must then read it
> as "until <condition>", or "while not <condition>" - either way, the
> code has to be mentally "translated"/restructured as it's being read).

It only has to if you persist in reading it as a while loop! If you
recognize
"while 1:" as a separate control construct, then there is much less of a
mental problem.


> So, to fix those problems a solution must:

> 1) Allow the loop's "load" code to exist just once, preferably
> somewhere near the terminating condition.
> 2) Have the terminating condition near the "while", and of the right
> "polarity".
> 3) To be Pythonic, have an obvious meaning.

See my comment, and the thread involving the [<statement>;...; <expression}
construct. It does everything you want. It also lets you put statements
in lambda expressions, which may prejudice a lot of people against it.

John Roth
More information about the Python-list mailing list