Testing conditions.

[Nick Coghlan]

Ray Gibbon wrote:
> 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.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net