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

[Andrew Barnert]

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.

> The "else" block is *unconditionally* executed after the "for" block.

The key difference is whether you treat "unless jumped out of" as meaning "unconditionally". I can see the sense of your way of looking at it (there's certainly a sense in which "while True:" loops "unconditionally", even if you have a break or return inside the loop, right?), so I understand where you're coming from.

However, I still think _most_ people who don't like for/else don't actually understand it. But of course I can see that as another argument against the naming--if it's confused this many people over the last 20 years, maybe it's inherently confusing?

At any rate, as you say at the end, there's no point arguing about this. The "else" clause isn't going to be renamed, and, even if it were, it wouldn't be reused for this new purpose, so that alternative to "empty" isn't worth discussing. (If I were designing a new Python-like language, I might rethink using "else"--but I don't think I'd use "then", or just leave it out the way Boo did.)