Home Original page

Conditional Expressions don't solve the problem

Kevin D salemail at dial.pipex.com
Thu Oct 18 04:32:44 EDT 2001 
Hi Greg,

Greg Ewing <greg at cosc.canterbury.ac.nz> wrote in message news:<3BCE26A1.727D3022 at cosc.canterbury.ac.nz>...
> Kevin D wrote:
> > 
> > while <condition>; <keyword> <assignment-statement>:
> >     <body>
> 
> Two drawbacks:
> 
> * The condition is written before the assigment, but
>   tested after it.

Right. When I was thinking about this (and I did give it a lot of
thought!) I decided that if it was going to be spelt "while" (or
"if"), then the condition had to come next. "While <statement>"
(especially where <statement> is an assignment with an '=' operator)
would just be confusing. That's what led me to believe that a
well-chosen "noise" keyword that made it read like English would solve
this drawback. I was working on the principle that if you read it out
loud, and you would just know what the code was doing - the "obvious
meaning" thing - then it must be close to being 'right'.

> * The statement part is restricted to a single statement
>   which must be an assignment.

I don't consider this a drawback - it's a feature! ;) Allowing
arbitrary statements at that point is almost guaranteed to lead to
abuse and obfuscated code. Strictly limiting it to a single assignment
statement (the tuple-unpacking version could be used if the condition
required more than one loop control variable) is, IMHO, akin to the
way in which, for example, Python prevents you nesting multiple 'if's
on a single line ("if a: b = c(); if b: d = e()" or somesuch - I know
this isn't possible because of ambiguities arising from no 'endif',
but hopefully you get my point that restricting things sometimes is
where Python does a good job of forcing readable code out of people).

Regards, Kev.
More information about the Python-list mailing list