Conditional Expressions don't solve the problem

[Kevin D]

Hi John,

"John Roth" <johnroth at ameritech.net> wrote in message news:<tsrfpg46ks9387 at news.supernews.com>...
> "Kevin D" <salemail at dial.pipex.com> wrote in message
> news:c2a5d721.0110170224.584a2d78 at posting.google.com...
> > 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).

Yes, sorry if I didn't make this clear - the duplication of code is
the "part of the argument for augmented assignment" that I was
referring to (the other (that I can remember) being the reduced amount
of attribute lookups, which doesn't apply here).

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

If it's not a while loop, it should not be spelled "while". That's
_exactly_ my point - you read one thing and then have to think
another. This impacts on the clarity of the code. "if" is not spelled
"because" for a very good reason ;)

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

Two problems: As you've mentioned with the lambda thing, making this
sort of thing a general construct may be it's undoing as it's easy to
abuse. My suggestion was quite strict in only allowing a single
assignment in which one can prep the condition control variables.

The other thing is that things look backwards when reading the code.
"while <statement>" just looks wrong, even if a condition eventually
occurs on the line. Something like "while <condition> where
<assignment-statement>" reads pretty much like English (to me) and
therefore requires the least amount of mental juggling to make sense
of, IMHO.

Also, note that I keep saying "something like" before my examples. I'm
not that tied to the exact syntax I'm suggesting, but I'm trying
(probably badly) to expand on what I think a Pythonic (read "obvious
meaning") solution to the root issues might look like.

Regards, Kev.