"also" to balance "else" ?

[Andrew Dalke]

Ron Adam wrote:
> 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.

As someone else pointed out, that problem could be resolved in
some Python variant by using a different name, like "at end".
Too late for anything before P3K.

> 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.

"It's been stated" is the passive tense.  You are one, and I
saw a couple others.  But it isn't the same as "many people say
that the current behavior is confusing."  If memory serves, I
don't even recall an FAQ on this, while there is a FAQ regarding
the case statement.

> 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.

There is a tension with code coherency.  In my version the code
that occurs a result of the condition is only in one place while
in yours its in two spots.

If all (>1) break statements in the loop have the same post-branch
code then it might make some sense.  But as I said, I don't think
it occurs all that often.

Given the Python maxim of
  There should be one-- and preferably only one --obvious way to do it.

which of these is the preferred and obvious way?

while f():
  print "Hello!"
  if g():
    break
else:
  print "this is a test"
also:
  print "this is not a pipe"

 -or-

while f():
  print "Hello!"
  if g():
    print "this is a test"
    break
else:
  print "this is not a pipe"


I prefer the second over the first.

Which of these is preferred?

while f():
  print "Hello"
  if g():
    a = 10
    print "world", a
    break
  if h():
    a = 12
    print "world",a
    break

  -or-

while f():
  print "Hello"
  if g():
    a = 10
    break
  if h():
    a = 12
    break
else:  # your else, not std. python's
  print "world", a

The latter is fragile, in some sense.  Suppose I added

  if hg():
    a = 14
    print "there"
    break

Then I have to change all of the existing code to put the
"else:" block back into the loop.

That for me makes it a big no.

>> 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.

Let me clarify.  When is it useful in real code?  Most cases
I can think of have corner cases which treat some paths different
than others.


> 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 argument for 'X' because it prevents people from asking for
some theoretical 'Y' isn't that strong.  Otherwise Python would
have had a goto years ago.

> 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.

Assuming you are talking about PEP 275 ("Switching on Multiple
Values"), how does this fulfill that need any better than the
existing if/elif/else chain?

> 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?

I disagree.  Given the "one -- and preferably only one -- obvious
way to do it" there is already a strong bias against language
features which exist only to do something another way but not
a notably better way.

> 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.

My guess is that it will be be hard.  There's no easy pattern
to grep for and I don't think the use case you mention comes up
often, much less often enough to need another control mechanism.

				Andrew
				dalke at dalkescientific.com