Ray said:
Before I resign myself to the inevitable, 'that's the way it is - get used
to it', I'd just like to scratch it once. But, before I try walking on very
thin ice, I want to ask whether there are expectations of some future
changes which address these issues?
I note PEP 3000 is silent on this matter, and PEP 315, though related, is
not relevant.
The nicest idea I've seen along these lines is:
if <expr> as <name>:
pass
elif <expr> as <name>:
pass
else:
pass
and
while <expr> as <name>:
pass
It's based on the idea of using 'as' to name caught exceptions in Python 3k
(which is in turn based on the use of as for renaming in import statements)
However, like allowing assignment, this approach breaks down as soon the thing
you want bound and the condition you want to test aren't the same, and then you
have to switch back to the 'bind before test' approach.
Which means a general solution has to allow *three* parts, not two:
1. A conditional expression
And optionally:
2. A subexpression to be named
3. The name for the subexpression
That is, something like:
if <expr> using <expr> as <name>:
pass
elif <expr> using <expr> as <name>:
pass
else:
pass
and
while <expr> using <expr> as <name>:
pass
(In the degenerate case where the condition is the thing we want named, it may
be possible to make the 'using' clause optional. If not, then the first
expression is simply <name>)
But such a solution involves an entirely new keyword and there's the eternal
question of whether the feature is needed *enough* to justify complicating the
syntax. The while case isn't good justification, since such while loops can
usually be converted to a generator function and a pair of for loops easily
enough. if/elif is slightly more promising as a motivation - having to convert
to nested if statements if you discover you need access to some part of the
condition test is a pain and the nested if's are harder to read that if/elif.
How common is that situation in reality, though? I can't think of a case where
I've had to use more than one nested if statement due to the 'problem' of not
being to do an embedded assignment.
*shrug* The issue has never really bothered me in practice. Heck, I often don't
use nested assignment even in C, since the buggers can be so damn hard to read.
That's mainly due to the = vs == problem though
Cheers,
Nick.