return in loop for ?

[yomgui]

hello,

is it legal to return inside a for loop
or am I obliged to break out of the loop before returning ?

thanks

yomgui

 

[Mike Meyer]

is it legal to return inside a for loop
or am I obliged to break out of the loop before returning ?

Try it and see:
.... for i in range(20):
.... if i > 10: return i
....
<mike

 

[yomgui]

Try it and see:

it is not because it does work on an implementation of python
that it will work on any other platform or in the futur.

yomgui

 

[Mike Meyer]

it is not because it does work on an implementation of python
that it will work on any other platform or in the futur.

That's true no matter how you arrive at your answer.

<mike

 

[Steve Holden]

That's true no matter how you arrive at your answer.

But, to answer the specific question, there's nothing in the language
definition that suggests the programmer should refrain from using a
return inside a loop, so for any implementation to impose such a
restriction would be a violation of the language definition.

Yomgui: I am not a language lawyer, but I think you can feel safe
returning from inside a loop. Just as a matter of interest, how else
would you propose to implement the functionality Mike showed:

... for i in range(20):
... if i > 10: return i
...

Python is supposed to cleanly express the programmer's intent. I can;t
think of a cleaner way that Mike's - can you?

regards
Steve

 

[bonono]

Yomgui: I am not a language lawyer, but I think you can feel safe
returning from inside a loop. Just as a matter of interest, how else
would you propose to implement the functionality Mike showed:


Python is supposed to cleanly express the programmer's intent. I can;t
think of a cleaner way that Mike's - can you?

Interestingly, I just saw a thread over at TurboGears(or is it this
group, I forgot) about this multiple return issue and there are people
who religiously believe that a function can have only one exit point.

def f():
r = None
for i in range(20):
if i > 10:
r = 10
break
if r is None: something
else: return r

 

[Steve Holden]

Steve Holden wrote:



Interestingly, I just saw a thread over at TurboGears(or is it this
group, I forgot) about this multiple return issue and there are people
who religiously believe that a function can have only one exit point.

def f():
r = None
for i in range(20):
if i > 10:
r = 10
break
if r is None: something
else: return r

Well, I'm happy in this instance that practicality beats purity, since
the above is not only ugly in the extreme it's also far harder to read.

What are the claimed advantages for a single exit point? I'd have
thought it was pretty obvious the eight-line version you gave is far
more likely to contain errors than Mike's three-line version, wouldn't
you agree?

regards
Steve

 

[bonono]

Well, I'm happy in this instance that practicality beats purity, since
the above is not only ugly in the extreme it's also far harder to read.

What are the claimed advantages for a single exit point? I'd have
thought it was pretty obvious the eight-line version you gave is far
more likely to contain errors than Mike's three-line version, wouldn't
you agree?

I thought it is about easier to spot error(that the return value is
done in single place) but didn't give too much attention as I don't buy
it. I call them "gotophobia"

 

[Duncan Booth]

To bonono, not Steve:

So if a function should religiously have only one exit point why does the
example you give have two exit points? i.e. the 'return r', and the implied
'return None' if you execute the 'something' branch.

Well, I'm happy in this instance that practicality beats purity, since
the above is not only ugly in the extreme it's also far harder to read.

What are the claimed advantages for a single exit point? I'd have
thought it was pretty obvious the eight-line version you gave is far
more likely to contain errors than Mike's three-line version, wouldn't
you agree?

Arguments include: any cleanup code you need when returning from a function
is all in one place (mostly applicable to languages where you have to do
your own memory management---see the recent AST discussion on the python
dev list); or it stops you accidentally forgetting to return a value (as
demonstrated above :^) )

In practice it is impossible to write code in Python (or most
languages) with only one return point from a function: any line could throw
an exception which is effectively another return point, so the cleanup has
to be done properly anyway.

 

[bonono]

To bonono, not Steve:

So if a function should religiously have only one exit point why does the
example you give have two exit points? i.e. the 'return r', and the implied
'return None' if you execute the 'something' branch.

I may have remember it wrong, but don't ask me. I am not the one
advocate of it. Oh, you mean the something. It is that I forgot what it
was, the original one did have one return.

Arguments include: any cleanup code you need when returning from a function
is all in one place (mostly applicable to languages where you have to do
your own memory management---see the recent AST discussion on the python
dev list); or it stops you accidentally forgetting to return a value (as
demonstrated above :^) )

The faintly remember it was about the last reason, or why it has been
brought up.

 

[Neil Hodgson]

Steve Holden:

What are the claimed advantages for a single exit point? I'd have
thought it was pretty obvious the eight-line version you gave is far
more likely to contain errors than Mike's three-line version, wouldn't
you agree?

Single exit point is an ancient Dijkstraism. It was one of the
constraints that were thought to be useful in the early days of
structured programming. Having function flow always terminate at the end
of the function does make analysis simpler. It helps with, for example,
managing resource lifetimes: its easy to forget to release something
when you add a return statement.

Yes, the rule has obvious shortcomings, but OTOH if it had enabled
reasonable formal verification...

http://en.wikipedia.org/wiki/Structured_programming#Multiple_points_of_exit

Neil

 

[Fredrik Lundh]

Yes, the rule has obvious shortcomings, but OTOH if it had enabled
reasonable formal verification...

I somehow find it hard to believe that you could write a multi-exit
function that cannot be trivially and automatically converted to a
single-exit function, for further analysis...

</F>

 

[Steve Holden]

Neil Hodgson wrote:




I somehow find it hard to believe that you could write a multi-exit
function that cannot be trivially and automatically converted to a
single-exit function, for further analysis...

Besides which I'm somewhat sceptical about formal verification methods.

While outwardly they apear to offer a technique for making software more
reliable there are two shortcomings I'm leery of. First, no verification
program can verify itself; secondly the requirements sepcifications for
formal verification are way beyond what a normal user is capable of
specifying, making them an even worse tool for specification.

regards
Steve

 

[Fredrik Lundh]

sepcifications

did you mean: sceptifications ?

(otoh, with 11,100 google hits, "sepcifications" should probably be
considered as a fully acceptable alternate spelling ;-)

</F>

 

[Steven D'Aprano]

Besides which I'm somewhat sceptical about formal verification methods.

While outwardly they apear to offer a technique for making software more
reliable there are two shortcomings I'm leery of. First, no verification
program can verify itself;

That's not a problem if there exists a verification program A which can't
verify itself but can verify program B, which in turn also can't verify
itself but will verify program A.

secondly the requirements sepcifications for
formal verification are way beyond what a normal user is capable of
specifying, making them an even worse tool for specification.

Can't argue with that observation

 

[Duncan Booth]

That's not a problem if there exists a verification program A which
can't verify itself but can verify program B, which in turn also can't
verify itself but will verify program A.

That is logically equivalent to the first case, so it doesn't get you
anywhere. (Just combine A and B into a single program which invokes A
unless the input is A when it invokes B instead.)

 

[Peter Hansen]

In practice it is impossible to write code in Python (or most
languages) with only one return point from a function: any line could throw
an exception which is effectively another return point, so the cleanup has
to be done properly anyway.

def funcWithGuaranteedOneExitPoint():
try:
# do some stuff, or
pass
finally:
return None

Of course, you might have mistyped something (e.g. "none") and still
manage to get an exception, but at least in the above example it's still
only a single exit point, even if not the one you thought it was. ;-)

-Peter

 

[Peter Hansen]

did you mean: sceptifications ?

(otoh, with 11,100 google hits, "sepcifications" should probably be
considered as a fully acceptable alternate spelling ;-)

Not if they're all in pages at site:holdenweb.com ! <grin>

 

[Scott David Daniels]

did you mean: sceptifications ?

QOTW!

I love it. I need to insert this in my vocabulary instantly!

--Scott David Daniels
(e-mail address removed)

 

[Roy Smith]

Interestingly, I just saw a thread over at TurboGears(or is it this
group, I forgot) about this multiple return issue and there are people
who religiously believe that a function can have only one exit point.

def f():
r = None
for i in range(20):
if i > 10:
r = 10
break
if r is None: something
else: return r

"Single entrance, single exit" is a philosophy (religion?) that's been
around for a while. The basic thought is that every code block should have
a single entrance and a single exit.

Back in the dark old days of gotos, there was a lot of spaghetti code
written with gotos jumping all over the place, even in and out of the
middle of loops. Then, in 1968, Dijkstra wrote his famous "Go To Statement
Considered Harmful" (http://www.acm.org/classics/oct95/) which spawned the
whole structured programming concept, and SESE is the logical outgrowth of
that.

The problem with SESE is that if you follow it strictly, you end up with
things like the example given above where you have to invent some temporary
variable, and an extra test at the end of the loop. The cure is worse than
the disease.

In any case, in a language which has exceptions, it's almost impossible to
really have true SESE, since an exception could be thrown from almost
anywhere. To be fair, there are those who use this to argue that
exceptions themselves are a bad thing. In my last job, the official style
guide said to not use exceptions in C++ because they generate confusing
flow of control, but I think that's becomming the minority view these days.