Add optional `if break:` suite to `for/while`

[pf_moore (Paul Moore)]

Personally, I think we should keep it simple. Tim’s proposal has a tight scope, with a clear justification to improve the common use case.

IMO this isn’t something that will be used a huge amount, but that’s perfectly fine.

@tim.one

I don’t care nearly so much about how odd it looks at first glance as about how hard it is to forget after it’s learned.

I strongly agree with this - there seems to be a common misconception in the Ideas category that language features need to be instantly understandable with no prior knowledge. Whereas what’s far more important, as you say, is whether it sticks in your mind after you’ve learned it.

[tim.one (Tim Peters)]

@jamestwebber

As @storchaka said, it seems like this would be a very obscure piece of syntax. Given how rarely most people would encounter it, I’m not sure there’s any spelling that will make it intuitive when it shows up.

Python has had for/else and while/else from the start, their syntax has never been intuitive to anyone, and never will be. They’re nevertheless useful. As already said to @storchaka, adding if break: doesn’t add new obscurity so much as it clarifies what’s already been obscure since the start. “Ah! I get into the if break: suite if there was a break, and the else: suite if there wasn’t”.

So long as Python loops have else: clauses (“forever” is a safe bet), that will remain so.

[dg-pb]

@tim.one

Possibly, although not to me yet. The advantage of if/else is that it faithfully reflects that exactly one of the branches will be taken. elif/else only reflects that at most one (If any) of the branches will be taken.

In this case, maybe could allow extra flexibility by not making it one statement.

while True:
    break
# caches whether break has occurred
# do whatever one wants here
a = 1
b = 2
if condition:
    # do stuff
elif break:
    # do stuff
else:
    # do stuff

And instead of modifying for/while, modification is needed for if/elif/else.

Then could also allow:

if not break:
    # do stuff

This would pretty much replace else extensions for anyone who finds it unreadable.

[tim.one (Tim Peters)]

@dg-pb

In this case, maybe could allow extra flexibility by not making it one statement.

No interest from me in “hyper-generalization” here. Maybe in a different topic. This topic is about an objectively minor tweak to the existing semantics and spelling of loop/else constructs.

[stoneleaf (Ethan Furman)]

@Nineteendo

Could you explain to me why adding a condition to the else would make it execute here?

The condition being tested is true – elif break is chosen when break is executed.

[Nineteendo (Nice Zombies)]

If an else block is not executed, adding a condition to it which is True, won’t make it execute:

if True:
    pass
elif True:
    print("this code won't be executed")

Can’t you see why this is confusing to me? It doesn’t behave the same as a regular elif.

[dg-pb]

@tim.one

No interest from me in “hyper-generalization” here. Maybe in a different topic.

Then, as of now, I am quite neutral between if and elif.

Maybe slightly positive on elif, as I think it would take me a while to get used to it being 1 and not 2 statements.

Syntax highlighting would be a life-saver here.

[tim.one (Tim Peters)]

@ntessore

Doesn’t manually raising a StopIteration (or maybe a custom exception) achieve this in a way that’s not too hard on the eyes?

That appears to be the preferred approach when needing to break out of multiple levels of loop (as your example did), but is generally gross overkill for the typically simpler “one loop level” cases. An additional level of indentation to stuff things in try/except, and “serious” code typically creates its own exception class.

I do that too, but I’m only aiming here at improving the more common one-loop cases, where break on its own is wholly sufficient.

[MegaIng (Cornelius Krupp)]

Would if break and ...: also be valid? What about if not break? I assume the answer is no, and that is IMO a problem - introducing magic multiple keyword sequences that look like they are a different feature is going to cause confusion.

I.e. the rule for if statements is “there is an expression that is being evaluated and if it’s truthy that is what happens”. break is not an expression, it doesn’t evaluate to a value and it isn’t truthy. While I somewhat like how it reads, I believe this will cause an infinite amount of confusion - even more than the else clause.

(I am however strongly opposed to using elif - I would always assume it is related to the else construct, when it is semantically the exact opposite. And everyone who learned about elif and else in the context of if-statements will do the same the first time)

[iritkatriel]

@tim.one

That appears to be the preferred approach when needing to break out of multiple levels of loop (as your example did), but is generally gross overkill for the typically simpler “one loop level” cases. An additional level of indentation to stuff things in try/except, and “serious” code typically creates its own exception class.

I do that too, but I’m only aiming here at improving the more common one-loop cases, where break on its own is wholly sufficient.

Actually your proposal would also help the multiple loop case:

for ...:
    for ...:
        break
    if break:
        break

But I’m not sure I want to write code like this, TBH.

[tim.one (Tim Peters)]

@MegaIng

Would if break and ...: also be valid? What about if not break? I assume the answer is no, and that is IMO a problem - introducing magic multiple keyword sequences that look like they are a different feature is going to cause confusion.

Nobody here yet has expressed the slightest confusion about what if break: is intended to mean in context. Quite the contrary, everyone appears to grasp it at once.

So I doubt the “confusion” spin. It’s a tiny learning curve, sure, but one-and-done.

if not break: could be added, but that’s already spelled else:, and “one obvious way” rules. if break and ... just reads like gibberish to me, so, no, I would not support that, no more than if as:. if break: is close to its plain English meaning.

[stoneleaf (Ethan Furman)]

@MegaIng

(I am however strongly opposed to using elif

Yeah, in writing out a longer example, I didn’t care for the elif version.

if break it is!

[zhangyx (Yuxuan Zhang)]

How about removing the preceding if?

for …:
    …
break:
    …
else:
    …

It should also be syntactically sound (i.e. would cause a syntax error otherwise)

[stoneleaf (Ethan Furman)]

@Nineteendo

If an else block is not executed, adding a condition to it which is True, won’t make it execute:

if True:
    pass
elif True:
    print("this code won't be executed")

Can’t you see why this is confusing to me? It doesn’t behave the same as a regular elif.

Sure, that’s confusing to me!

But the suggestion is to add if break, which is not the same as adding if True.

Can you explain why you are seeing it that way?

[ayhanfuat (Ayhan Ç.)]

if break by itself is not confusing but if that is legal I would expect the following to be legal as well.

for …:
    …
if break and this:
    …
elif break and that:
    …

Not saying it should be. But the choice of using if would create this expectation for me.

[jamestwebber (James Webber)]

@tim.one

Nobody here yet has expressed the slightest confusion about what if break: is intended to mean in context. Quite the contrary, everyone appears to grasp it at once.

That’s because you explained it in the OP, and people are taking your proposal as given. That’s not how anyone else will encounter it–they’ll likely encounter it by reading some code that uses it.

[stoneleaf (Ethan Furman)]

@tim.one

Nobody here yet has expressed the slightest confusion about what if break: is intended to mean in context.

@jamestwebber

That’s because you explained it in the OP, and people are taking your proposal as given. That’s not how anyone else will encounter it–they’ll likely encounter it by reading some code that uses it.

Even without the proposal, if break is self-explanatory. What else could it mean besides the previous loop ended via a break?

[zhangyx (Yuxuan Zhang)]

@zhangyx

for …:
    …
break:
    …
else:
    …

Elaborating a bit on how the above syntax could work for the following idea:

@iritkatriel

It allows you to have a different value for different breaks:

    for x in ...:
        if cond1:
                 break f(x)
        elif cond2:
                 break g(x)
    if break as v:
        ...

We can make break work like a match - case:

for x in ...:
    if cond1:
         break "success", result
    elif cond2:
         break "fail", reason
break ("success", result):
    ... # On success
break ("fail", reason):
    ... # On fail
break:
    .... # Wildcard
else:
    .... # No result

[tim.one (Tim Peters)]

@zhangyx

How about removing the preceding if?

If like if break: better:

• While break: is a syntax error now, break; is not, and in the editor font I usually use for writing code the difference between a semicolon and a colon is tiny. Compounded by that the only difference in typing them is whether the SHIFT key is depressed. Too error-prone for me, both for writing and reading.
• if plays perfectly with the existing else. break/else just looks confused .

[zhangyx (Yuxuan Zhang)]

@tim.one

in the editor font I usually use for writing code the difference between a semicolon and a colon is tiny

This felt like a strong argument at first glance, but then I realized the actual difference lies in the lines following it - a break: clause will be followed by indented code, which makes it super obvious