"also" to balance "else" ?

[Ron Adam]

There seems to be a fair amount of discussion concerning flow control
enhancements lately. with, do and dowhile, case, etc... So here's my
flow control suggestion. ;-)
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.

'also' would be the opposite of 'else' in meaning. And in the case of a
for-else... would correct what I believe to be an inconsistency.
Currently the else block in a for loop gets executed if the loop is
completed, which seems backwards to me. I would expect the else to
complete if the loop was broken out of. That seems more constant with
if's else block executing when if's condition is false.
'also' would work like this.

for x in <iteriable>:
BLOCK1
if <condition>: break # do else block
also:
BLOCK2
else:
BLOCK3

where the also block is executed if the loop completes (as the current
else does), and the else block is executed if it doesn't.
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.
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.
And 'tentatively'<g >, there is the possible 'alif', (also-if), to be
used this way.

if <condition1>:
BLOCK1
alif <condition2>:
BLOCK2
break # skip to also block
alif <condition3>:
BLOCK3
alif <condition4>:
BLOCK4
also: # at lease one condition was true
BLOCK5
else: # no conditions evaluated as true
BLOCK6

Where only one elif will ever evaluate as true, any or all 'alif's could
evaluate as true. This works similar to some case statements except all
alif conditions may be evaluated. Not a true case statement, but a good
replacement where speed isn't the main concern?

I'm not sure if 'elif's and 'alif's could or should be used together?
Maybe a precedence rule would be needed. Or simple that all also's and
alif's must precede any elif's. Then again maybe alif's between elif's
could be useful? For example the alif <condition2> could be and 'elif'
instead, so the break above would't be needed.

'also' can be used without the else in the above examples, and of course
the 'else' doesn't need an 'also'.

I think this gives Pythons general flow control some nice symmetrical
and consistent characteristics that seem very appealing to me. Anyone
agree?

Any reason why this would be a bad idea? Is there an equivalent to an
also in any other language? (I haven't seen it before.)

Changing the for-else is probably a problem... This might be a 3.0 wish
list item because of that.

Is alif too simular to elif?

On the plus side, I think this contributes to the pseudocode character
of Python very well.

Cheers, Ron

[Eloff]

My first reaction was that this is terrible, else clauses on loops are
confusing enough. But if I think about it more, I'm warming up to the
idea. Also/Else for loops is clear, symmetrical, and would be useful.

Reversing the meanign of else will break code, but it's not used that
frequently, and it was a confusing thing to begin with, nothing wrong
in breaking something (slowly!) if it was 'broken' to begin with.

Alifs look evil, I couldn't deduce the control flow very easily, but
then they are a new idea. I'll keep an open mind on that one.

I think the best thing would be to compare the also/else syntax to what
identical functionality looks like in python now [hint to someone with
more time than me right now ;)]. I'd vote for whichever is the more
concise and readable of the two.

-Dan

[Andrew Dalke]

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

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;bre ak" occurs multiple times in
the loop. My intuition is that that doesn't occur often
enough to need a new syntax to simplify it.

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

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

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
da***@dalkescie ntific.com

[Ron Adam]

Eloff wrote:

My first reaction was that this is terrible, else clauses on loops are
confusing enough. But if I think about it more, I'm warming up to the
idea. Also/Else for loops is clear, symmetrical, and would be useful.

Reversing the meanign of else will break code, but it's not used that
frequently, and it was a confusing thing to begin with, nothing wrong
in breaking something (slowly!) if it was 'broken' to begin with.

Alifs look evil, I couldn't deduce the control flow very easily, but
then they are a new idea. I'll keep an open mind on that one.
Yes, it's probably because it's new. Alifs would be used where you want
to test for multiple possible values, and need to respond differently
depending on the values. They probably wouldn't be used as often as elifs.

alifs is a way to string if's together as a group. The following would
be equivalent to if-alif-also-else.

didif = False
if val == condition1:
didif = True
BLOCK1
if val == condition2:
didif = True
BLOCK2
if val == condition3:
didif = True
if didif:
BLOCK3
else:
BLOCK4
The if-alif-also-else version doesn't need the extra name to mark if any
of the conditions were true.

if val == condition1:
BLOCK1
alif val == condition2:
BLOCK2
alif val == condition3:
BLOCK3
also:
BLOCK4
else:
BLOCK5

But I think we will need to find some real use case's to make it
convincing.

I think the best thing would be to compare the also/else syntax to what
identical functionality looks like in python now [hint to someone with
more time than me right now ;)]. I'd vote for whichever is the more
concise and readable of the two.

-Dan

In cases of if-also, the equivalent code needs an extra local variable
and an additional if statement.

iftest = False
if <condition>:
iftest = True
BLOCK1
elif <condition>:
iftest = True
BLOCK2
if iftest:
BLOCK3

This is the pattern that caused me to think of having an also. I was
parsing and formatting doc strings at the time, and also would allow it
to become.

if <condition>:
BLOCK1
elif <condition>:
BLOCK2
also:
BLOCK3

Which is much easier to read.
Ron

[John Roth]

"Ron Adam" <rr*@ronadam.co m> wrote in message
news:H6******** ************@to rnado.tampabay. rr.com...

Currently the else block in a for loop gets executed if the loop is
completed, which seems backwards to me. I would expect the else to
complete if the loop was broken out of. That seems more constant with
if's else block executing when if's condition is false.

Actually, it makes sense if you look at it correctly.

In an unadorned loop, exits via break and via the
loop condition becoming false go to the same place.
To distinguish requires some kind of a switch.

In a loop with an else, exits via break skip the else
clause, while an exit via the loop condition takes
the else clause. You don't need a special exit on
break since you can put any amount of logic after
the if and in front of the break. Where you need it
is on exit via the loop condition.

The difficulty you're having with this is that else
is a very bad keyword for this particular construct.
I'd prefer something like "on normal exit" as
a keyword.

John Roth

[Ron Adam]

John Roth wrote:

"Ron Adam" <rr*@ronadam.co m> wrote in message
news:H6******** ************@to rnado.tampabay. rr.com...

Currently the else block in a for loop gets executed if the loop is
completed, which seems backwards to me. I would expect the else to
complete if the loop was broken out of. That seems more constant with
if's else block executing when if's condition is false.

Actually, it makes sense if you look at it correctly.

In an unadorned loop, exits via break and via the
loop condition becoming false go to the same place.
To distinguish requires some kind of a switch.

In a loop with an else, exits via break skip the else
clause, while an exit via the loop condition takes
the else clause. You don't need a special exit on
break since you can put any amount of logic after
the if and in front of the break. Where you need it
is on exit via the loop condition.

The difficulty you're having with this is that else
is a very bad keyword for this particular construct.
I'd prefer something like "on normal exit" as
a keyword.

It's not a difficulty. This is the point I was making. :)

My suggestion is to use, also as the keyword to mean "on normal exit"
'also' do this.

Ron

[Terry Hancock]

On Monday 13 June 2005 11:09 pm, Ron Adam wrote:

John Roth wrote:

"Ron Adam" <rr*@ronadam.co m> wrote in message
news:H6******** ************@to rnado.tampabay. rr.com...
The difficulty you're having with this is that else
is a very bad keyword for this particular construct.
I'd prefer something like "on normal exit" as
a keyword.

It's not a difficulty. This is the point I was making. :)

My suggestion is to use, also as the keyword to mean "on normal exit"
'also' do this.

Unfortunately, "also" is also a bad keyword to use for this, IMHO.
I don't find it any more intuitive than "else". (And since your idea
would break if-else code, I don't think it would be allowed, anyway).

I can't think of what would be a better keyword, though. :-/

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[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;bre ak" 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
da***@dalkescie ntific.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

[Ron Adam]

Terry Hancock wrote:

On Monday 13 June 2005 11:09 pm, Ron Adam wrote:

My suggestion is to use, also as the keyword to mean "on normal exit"
'also' do this.

Unfortunately, "also" is also a bad keyword to use for this, IMHO.
I don't find it any more intuitive than "else". (And since your idea
would break if-else code, I don't think it would be allowed, anyway).

Hi Terry,

How would it break the current if-else?
I can't think of what would be a better keyword, though. :-/

Well there's 'not-else' or 'nelse' Ack! Just kidding of course.

Yes, I can't think of anything that has the same meaning that would
work. 'And' would be the English language alternative to "else", but
it's already used of course.
Regards, Ron

[Fredrik Lundh]

"praba kar" wrote:

I have doubt regarding headers in cgi
programming. If I gives "Content-Type:text/plain"
then I try to print html contents. Is right or wrong
after giving content-type: text/plain?

if you expect the HTML contents to appear as HTML, it's wrong.

(some web browsers may display it as HTML even if it's tagged
as something else, but you shouldn't rely on this)

</F>