"also" to balance "else" ?

[Ron Adam]

Andrew Dalke wrote:

> Ron Adam wrote:
> 
>>It occurred to me (a few weeks ago while trying to find the best way to 
>>form a if-elif-else block, that on a very general level, an 'also' 
>>statement might be useful.  So I was wondering what others would think 
>>of it.
> 
> 
>>for x in <iteriable>:
>>    BLOCK1
>>    if <condition>: break   # do else block
>>also:
>>    BLOCK2
>>else:
>>    BLOCK3
> 
> 
> 
> For this specific case you could rewrite the code in
> current Python as
> 
> for x in <iterable>:
>   BLOCK1
>   if <condition>:
>     BLOCK3
>     break
> else:
>   BLOCK2

True, but I think this is considerably less clear.  The current for-else 
is IMHO is reversed to how the else is used in an if statement.


> In order for your proposal to be useful you would need an
> example more like the following in current Python
> 
> for x in <iterable>:
>   ...
>   if <condition>:
>     BLOCK3
>     break
>   ...
>   if <condition>:
>     BLOCK3
>     break
> else:
>   BLOCK2
> 
> That is, where "BLOCK3;break" occurs multiple times in
> the loop.  My intuition is that that doesn't occur often
> enough to need a new syntax to simplify it.

I think you have BLOCK 2 and 3 confused here.  BLOCK2 is the 'also' 
block above.  The current for-else already does the 'also' behavior. I'm 
asking if changing the current 'else' in a for statement to 'also' would 
make it's current behavior clearer.  It's been stated before here that 
current behavior is confusing.

You are correct that the 'else' behavior could be nested in the if:break 
statement.  I think the logical non-nested grouping of code in the 
for-also-else form is easier to read.  The block in the if statement 
before the break isn't part of the loop, IMO,  being able to move it to 
after the loop makes it clear it evaluates after the loop is done.

> Can you point to some existing code that would be improved
> with your also/else?
> 
> 
>>while <condition1>:
>>     BLOCK1
>>     if <condition2>: break    # jump to else
>>also:
>>     BLOCK2
>>else:
>>     BLOCK3
>>
>>Here if the while loop ends at the while <condition1>, the BLOCK2 
>>executes,  or if the break is executed, BLOCK3 executes.
> 
> 
> which is the same (in current Python) as
> 
> 
> while <condition>:
>   BLOCK1
>   if <condition2>:
>     BLOCK3
>     break
> else:
>   BLOCK2

Actually, my example above has a problem, it conflicts with the current 
while else.  Probably the while-also-else should behave the same as an 
if-also-else.  Maybe more thinking on how the break behaves in relation 
to these is needed.


>>In and if statement...
>>
>>if <condition1>:
>>     BLOCK1
>>elif <condition2>:
>>     BLOCK2
>>elif <condition3>:
>>     BLOCK3
>>also:
>>     BLOCK4
>>else:
>>     BLOCK5
>>
>>Here, the also block would execute if any previous condition is true, 
>>else the else block would execute.
> 
> 
> That is ... funky.  When is it useful?

Any time you've writen code that repeats a section of code at the end of 
all the if/elif statements or sets a variable to check so you can 
conditionally execute a block of code after the if for the same purpose.

> One perhaps hackish solution I've done for the rare cases when
> I think your proposal is useful is
> 
> while 1:
>   if <condition1>:
>     BLOCK1
>   elif <condition2>:
>     BLOCK2
>   elif <condition3>:
>     BLOCK3
>   else:
>     # couldn't do anything
>     break
>   BLOCK4
>   break
> 

The type of thing I would try to avoid. ;-)


>>I think this gives Pythons general flow control some nice symmetrical 
>>and consistent characteristics that seem very appealing to me.  Anyone 
>>agree?
> 
> 
> No.  Having more ways to do control flow doesn't make for code that's
> easy to read.

I agree that having more ways isn't a reason by it self.

My thinking is that this would be the type of thing that would be used 
to argue against more specialized suggestions.  ie...   No a <fill in 
new suggested keyword here> isn't needed because the also-else form 
already does that.  ;-)

An example of this might be the case statement suggestions which have 
some support and even a PEP.  The if-alif-also-else works near enough to 
a case statement to fulfill that need.  'alif' (also-if) could  be 
spelled 'case' and maybe that would be clearer as many people are 
already familiar with case statements from other languages.

Vetoing a suggestion on grounds of it can be done in another way, is 
also not sufficient either as by that reasoning we would still be using 
assembly language.  So the question I'm asking here is can an inverse to 
  the 'else' be useful enough to be considered?


> My usual next step after thinking (or hearing) about a new Python
> language change is to look at existing code and see if there's
> existing code which would be easier to read/understand and get an
> idea if it's a common or rare problem.  Perhaps you could point
> out a few examples along those lines?
> 
> 				Andrew
> 				dalke at dalkescientific.com

I'll try to find some use case examples tomorrow, it shouldn't be too 
hard.  It probably isn't the type of thing that going to make huge 
differences.  But I think it's a fairly common code pattern so shouldn't 
be too difficult to find example uses from pythons library.

Regards, Ron