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]

Re: return in loop for ?

yomgui <not@valid.or g> writes:[color=blue]
> is it legal to return inside a for loop
> or am I obliged to break out of the loop before returning ?[/color]

Try it and see:
[color=blue][color=green][color=darkred]
>>> def f():[/color][/color][/color]
.... for i in range(20):
.... if i > 10: return i
....[color=blue][color=green][color=darkred]
>>> print f()[/color][/color][/color]
11[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[yomgui]

Re: return in loop for ?

Mike Meyer wrote:[color=blue]
>
> yomgui <not@valid.or g> writes:[color=green]
> > is it legal to return inside a for loop
> > or am I obliged to break out of the loop before returning ?[/color]
>
> Try it and see:[/color]

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]

Re: return in loop for ?

yomgui <not@valid.or g> writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> yomgui <not@valid.or g> writes:[color=darkred]
>> > is it legal to return inside a for loop
>> > or am I obliged to break out of the loop before returning ?[/color]
>> Try it and see:[/color]
> it is not because it does work on an implementation of python
> that it will work on any other platform or in the futur.[/color]

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

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steve Holden]

Re: return in loop for ?

Mike Meyer wrote:[color=blue]
> yomgui <not@valid.or g> writes:
>[color=green]
>>Mike Meyer wrote:
>>[color=darkred]
>>>yomgui <not@valid.or g> writes:
>>>
>>>>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:[/color]
>>
>>it is not because it does work on an implementation of python
>>that it will work on any other platform or in the futur.[/color]
>
>
> That's true no matter how you arrive at your answer.
>[/color]
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:
[color=blue][color=green][color=darkred]
> >>>def f():[/color][/color]
>
> ... for i in range(20):
> ... if i > 10: return i
> ...
>[/color]

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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[bonono@gmail.com]

Re: return in loop for ?


Steve Holden wrote:
[color=blue]
> 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:
>[color=green][color=darkred]
> > >>>def f():[/color]
> >
> > ... for i in range(20):
> > ... if i > 10: return i
> > ...
> >[/color]
>
> Python is supposed to cleanly express the programmer's intent. I can;t
> think of a cleaner way that Mike's - can you?[/color]
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]

Re: return in loop for ?

bonono@gmail.co m wrote:[color=blue]
> Steve Holden wrote:
>
>[color=green]
>>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:
>>
>>[color=darkred]
>>>>>>def f():
>>>
>>>... for i in range(20):
>>>... if i > 10: return i
>>>...
>>>[/color]
>>
>>Python is supposed to cleanly express the programmer's intent. I can;t
>>think of a cleaner way that Mike's - can you?[/color]
>
> 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
>[/color]
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[bonono@gmail.com]

Re: return in loop for ?


Steve Holden wrote:[color=blue]
> 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?
>[/color]
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]

Re: return in loop for ?

Steve Holden wrote:
[color=blue][color=green]
>> 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
>>[/color][/color]

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.
[color=blue]
> 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?
>[/color]
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@gmail.com]

Re: return in loop for ?


Duncan Booth wrote:[color=blue]
> 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.[/color]
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.
[color=blue]
> 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 :^) )[/color]
The faintly remember it was about the last reason, or why it has been
brought up.

[Neil Hodgson]

Re: return in loop for ?

Steve Holden:
[color=blue]
> 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?[/color]

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]

Re: return in loop for ?

Neil Hodgson wrote:
[color=blue]
> Yes, the rule has obvious shortcomings, but OTOH if it had enabled
> reasonable formal verification...[/color]

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]

Re: return in loop for ?

Fredrik Lundh wrote:[color=blue]
> Neil Hodgson wrote:
>
>[color=green]
>> Yes, the rule has obvious shortcomings, but OTOH if it had enabled
>>reasonable formal verification...[/color]
>
>
> 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...
>[/color]
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Steven D'Aprano]

Re: return in loop for ?

On Thu, 24 Nov 2005 11:06:58 +0000, Steve Holden wrote:
[color=blue]
> 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;[/color]

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.

[color=blue]
> 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.[/color]

Can't argue with that observation :-)

--
Steven.

[Fredrik Lundh]

Re: return in loop for ?

Steve Holden wrote:
[color=blue]
> sepcifications[/color]

did you mean: sceptifications ?

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

</F>