[Python-ideas] Control Flow - Never Executed Loop Body

[Franklin? Lee]

On Mar 20, 2016 10:10 PM, "Andrew Barnert via Python-ideas" <
python-ideas at python.org> wrote:
>
> On Mar 20, 2016, at 18:32, Steven D'Aprano <steve at pearwood.info> wrote:
> >
> >> On Sun, Mar 20, 2016 at 01:16:50PM -0700, Andrew Barnert via
Python-ideas wrote:
> >>> On Mar 20, 2016, at 11:12, Sven R. Kunze <srkunze at mail.de> wrote:
> >>>
> >>> Issues
> >>> People I talked to suggested "else" as an alternative to "empty"
because "empty is not quite clear". Unfortunately, "else" is already taken
and is itself not quite clear. "then" has been proposed as an alternative
for "else" in an attempt for proper understanding of "else". If that would
be an accepted proposal, it would make room for "else" to be used for the
usage of the "empty keyword proposed here.
> >>
> >> Besides the backward compatibility issue, changing "else" to "then"
> >> would be horribly confusing. I suspect anyone who thinks that would be
> >> an improvement doesn't actually understand or like for...else, and
> >> they'd be happier just eliminating it, not renaming it.
> >
> > "then" is my idea, and not only do I understand "for...else", but I like
> > it and use it, and certainly don't want to eliminate it. I just hate the
> > keyword used.
> >
> > Let me just start by saying that I realise that actually changing
> > "for...else" to "for...then" is at least 8 years too late, so I know
> > this is a non-starter. It would be particularly confusing to change
> > "else" to "then" AND add a new "else" with different semantics at the
> > same time.
> >
> >> An else clause is testing that no break was hit inside the loop. Look
> >> at a typical example:
> >
> > That's one way of thinking about it. But I don't think it is helpful to
> > think of it as setting an invisible flag "a break was hit inside the
> > loop", and then testing it. I think that a more natural way to think
> > about it is that "break" jumps out of the entire for...else compound
> > statement. This has the big advantage that it actually matches what the
> > byte code does in all the versions I've looked at.
>
> The way I've always thought about it is that it's more like a try/else
than an if/else: it runs unless you've jumped out of the whole for
statement (via break instead of raise). I think Nick Coghlan has a blog
post that explains this very nicely, showing both the novice-understandable
intuition and how a theoretical Python implementation could implement it
(which is close to how CPython actually does, but maybe simpler), so I
won't go over the details here.
>
> From what you write later, you also don't like the naming of try/else--in
which case it's not surprising that you don't like the naming of for/else.

I read the "else:", when attached to "try:", as "alternative to except:"
(which makes sense even if no explicit "except" block exists). In
"if-else", it means "alternative to if:" (or "if: and elif:"). If
"switch-case" existed, "else:" would mean "alternative to case:". But in
"for:"/"while:", there is no block keyword that the "else:" is the
alternative to. It definitely isn't the alternative to the loop block
itself, but that's probably the most common wrong intuition.

(Disclaimer: I use "for-else" and "try-else" when I can. I don't dislike
them at all. I'm just trying to explain the newbie confusion.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160320/3fd9248c/attachment.html>