Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Michael Selik <michael.selik@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: for / while else doesn't make sense
Date: Tue, 14 Jun 2016 04:37:31 +0000
Lines: 72
Message-ID: <mailman.54.1465879063.2288.python-list@python.org>
References: <CAHJ7fxhOeKFbu3=Jso=wgpBnH9Opr_J_6SHLDO+KtAqVFeGHnA@mail.gmail.com> <mailman.36.1463676220.27390.python-list@python.org> <9e7b6ded-15ad-490a-9842-b3da5d8a048d@googlegroups.com> <575d3430$0$11108$c3e8da3@news.astraweb.com> <CAGgTfkOG7SBX_OsnnbjZKMCPYxnaLB6XxHmqg5MLxOiLYHQpug@mail.gmail.com> <mailman.23.1465758525.2288.python-list@python.org> <575e167a$0$1608$c3e8da3$5496439d@news.astraweb.com> <CAGgTfkMCYXgLzPYYY5N7oNhvbNMAYyPuzenOqVB=qLPnxtNHRA@mail.gmail.com> <mailman.47.1465861566.2288.python-list@python.org> <575f6f58$0$1591$c3e8da3$5496439d@news.astraweb.com> <CAGgTfkMsfcFqUnLx+e5+WR8vvYt4d3RC_xn5zJgKuWP-LS9iEA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <575f6f58$0$1591$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:109925

On Mon, Jun 13, 2016 at 10:46 PM Steven D'Aprano <steve@pearwood.info>
wrote:

> On Tue, 14 Jun 2016 09:45 am, Michael Selik wrote:
> > On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <steve@pearwood.info>
> > wrote:
> >> On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote:
> >> > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano <
> >> > steve+comp.lang.python@pearwood.info> wrote:
> >> >
> >> >> - run the for block
> >> >> - THEN unconditionally run the "else" block
> >> >>
> >> > Saying "unconditionally" is a bit misleading here. As you say, it's
> >> > conditioned on completing the loop without break/return/raise.
> >>
> >> It's also conditional on the OS not killing the Python process,
> >> conditional on the CPU not catching fire, conditional on the user not
> >> turning the power of, and conditional on the sun not exploding and
> >> disintegrating the entire earth.
> >>
> >> In the absence of any event which interferes with the normal execution
> of
> >> code by the Python VM, and in the absence of one of a very few
> >> explicit "JUMP" statements which explicitly jump out of the compound
> >> for...else statement, the else clause is unconditionally executed afte=
r
> >> the for clause.
>
> > Saying that ``raise``, ``break``, and ``return`` are "one of a very few
> > explicit JUMP statements" implies that they are obscure.
>
> What? No. How do you get that?
>

The context. That was right after a list of several (mostly) oddball
situations. In my experience, that pattern of speech is usually used to
imply that everything listed is also exceptionally strange.

There's a simple mental model, one which has the advantage of actually
> matching the implementation: for...else executes else unconditionally, ..=
.
> If Python 3.6 introduces a GOTO command, then my mental model of
> for...else doesn't need to change.
>

That's a good explanation. The documentation says, "A break statement
executed in the first suite terminates the loop without executing the else
clause=E2=80=99s suite." Do you think that qualification of "without execut=
ing the
else clause" is unnecessary/redundant?

Regardless of the implementation, I think that explanation -- if break,
then skip the else-clause -- helps clarify the purpose.

https://docs.python.org/3/reference/compound_stmts.html#the-for-statement

else: # only if no break occurs
> and then I would feel guilty for lying, because that comment is not, in
> fact, correct. Returning out of the function from inside the loop will al=
so
> avoid running the else part, as will an exception.
>

I absolve you of guilt! :-) If you had written, "guaranteed to run if no
break," then lawyers will come after you. If you had written "if and only
if" some mathematicians might complain. As you wrote it, it's actually true=
.

An "if and only if" logical statement has two parts: "if no break, run
else-clause" and "if break, do not run else-clause". As you say, the first
part is false. But you only made the latter claim.