Conditional Expressions don't solve the problem

[John Roth]

"Kevin D" <salemail at dial.pipex.com> wrote in message
news:c2a5d721.0110180034.58fd2af4 at posting.google.com...
> 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...
> > > 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 ;)

I suppose that is a difference in the way our minds work. After far
too many languages, my mind simply recognizes it as an idiom, and
primes me to look for the loop controlling if... break construct
embedded in it.

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

I find "too easy to abuse" somewhat of a straw man. You can
abuse almost anything, and Python already has some really obscure
usages. The short circuit 'and' and 'or' are positively obvious compared
to the short-circuit '<' ,'<=', '>' and '>='.

As a frequent poster to the XP newsgroup, I don't regard 'easy to
abuse' as a cardinal sin, unless it's "almost impossible to avoid abusing."
Now, that is a sin.

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

As I said in another post, I suspect that iterators will solve most of
the cases in the 'while 1:" camp. I'm much more interested in using
such a construct with 'elif', and for that I need multiple statements.

John Roth
>
> Regards, Kev.