if/elif chain with assignment expressions

[Fernando Perez]

Neil Hodgson wrote:

>    I hope this does not change as it makes analysis of the code easier.
> Reading and understanding code is as important as writing it. Analysis of a
> problem depends as much on restricting the set of possible causes ('it is
> *not* the case that') as it does on generating a larger set of possible
> causes ('it is the case that'). Pruning the possible cause tree is extremely
> valuable and Python cooperates with a well thought out set of restrictions.
> Being able to depend on the absence of assignments in if and while
> statements is a benefit when fixing Python code over C/C++. Characterizing
> these as "training wheels" and thus only of use to beginners is
> unreasonable.

Well, the problem here (and apparently others share this opinion) is that this
particular restriction genuinely forces kludgy code in certain circumstances. 
As John Roth pointed out, the looping case is easily solved with iterators, but
Paul's original one is not.

I know that the if(x=0) bug in C/C++ is a potentially nasty one, having been
bitten by it myself in the past.  It is also true that having this particular
option available allows certain kinds of code to be written in a clear and
concise manner.  So yes, it is a slightly dangerous feature, but one which
offers true expressive power.  Hence my characterization of it as 'training
wheels': I don't mean to say that only beginners can fall into the trap (even
Lance Armstrong can fall off a bike), but rather that experienced users will
know what to watch for, and will be willing to pay the price of potentially
falling for the liberty of going faster :)

Cheers,

f