Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #91821 > unrolled thread

for...else

Back to article view | Back to comp.lang.python

Contents

  for...else acdr <mail.acdr@gmail.com> - 2015-06-02 13:26 +0200
    Re: for...else Rustom Mody <rustompmody@gmail.com> - 2015-06-03 07:40 -0700
      Re: for...else Laura Creighton <lac@openend.se> - 2015-06-03 18:57 +0200

#91821 — for...else

Hi,

Currently, in various places in my code, I have the equivalent of:

for x in it:
    if complicated_calculation_1():
        cleanup()
        break
    complicated_calculation_2()
    if complicated_calculation_3():
        cleanup()
        break

Obviously, I'm repeating myself by having two separate calls to
cleanup(). I can't really see a nicer way to do this. (Though I see
plenty of non-nice ways to do this, such as adding "broken = True" in
front of every "break", and then after the loop is done, have an "if
broken" section.) Other solutions that I'm not particularly fond of
can be found on stackexchange, where someone else is trying to do the
same thing:
http://stackoverflow.com/questions/3296044/opposite-of-python-for-else

I'm wondering if there is a demand for expanding the "for...else"
functionality to be expanded also have a block of code that only gets
called if the loop is broken out of. I.e.:

for x in it:
    ...
then:
    # "break" was called
    ...
else:
    # "break was not called
    ...

[toc] | [next] | [standalone]

#91968

On Tuesday, June 2, 2015 at 4:56:57 PM UTC+5:30, acdr wrote:
> Hi,
> 
> Currently, in various places in my code, I have the equivalent of:
> 
> for x in it:
>     if complicated_calculation_1():
>         cleanup()
>         break
>     complicated_calculation_2()
>     if complicated_calculation_3():
>         cleanup()
>         break
> 
> Obviously, I'm repeating myself by having two separate calls to
> cleanup(). I can't really see a nicer way to do this. (Though I see
> plenty of non-nice ways to do this, such as adding "broken = True" in
> front of every "break", and then after the loop is done, have an "if
> broken" section.) Other solutions that I'm not particularly fond of
> can be found on stackexchange, where someone else is trying to do the
> same thing:
> http://stackoverflow.com/questions/3296044/opposite-of-python-for-else
> 
> I'm wondering if there is a demand for expanding the "for...else"
> functionality to be expanded also have a block of code that only gets
> called if the loop is broken out of. I.e.:
> 
> for x in it:
>     ...
> then:
>     # "break" was called
>     ...
> else:
>     # "break was not called
>     ...

This question prompts a counter question whose answer Ive been hunting 
unsuccessfully for a while.

The well-known Bohm-Jacopini theorem says that any goto-based program can be
de-goto-ized using booleans:
http://en.wikipedia.org/wiki/Structured_program_theorem.

However there is a complementary theorem (due to Knuth??) that the exact details and sequence of tests performed in the unstructured and the structurized versions may be significantly different.
IOW the unstructured program can be significantly more efficient.

Does anyone know/have the reference to this other theorem?

[toc] | [prev] | [next] | [standalone]

#91977

Are you looking for Knuth's paper Structured Programming with Goto Statements?
http://c2.com/cgi/wiki?StructuredProgrammingWithGoToStatements

I don't remember a theorem in there, but I haven't read it for decades,
so ...

Laura

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web