LWN: Comments on "Python multi-level break and continue"

Python multi-level break and continue

mathstuf — Fri, 01 Dec 2023 04:04:55 +0000

Rust has it as well: https://doc.rust-lang.org/rust-by-example/flow_control/lo...

Python multi-level break and continue

blommaep — Wed, 29 Nov 2023 16:16:12 +0000

The labeled loop is not only safe, it is also the most clean construct for such cases (nested loops with 'short' body).
It's easy to write: you never need to doubt where the break/continue will jump, no special constructions
It's easy to read: just find the label
I really fail to understand why it only exists in perl

Python multi-level break and continue

sammythesnake — Mon, 19 Sep 2022 12:04:06 +0000

I actually really like this - to my mind it answers all the qualms I've had and AFAICS those others have expressed (based on the article/comments here - I've not read the threads)

It's easy to read, nicely encourages clear naming/labeling (at least in a much as a syntactic requirement to *have* a label), requires no extra charges to the language...

The only niggle is that the syntax of having a method call serve the purpose of a flow control construct is a *little" klunky...

It's even the kind of thing that might make a good library/module, even if an unusually small one :-P - perhaps a candidate to be included in an already existing standard library module (¿itertools?)

Some thoughts on how it could be expanded - more hands-holding support for more styles of loops, such as specific buttons for while/until/for/whatever. Perhaps parameters to the init of the Loop class would be the place to do that: "with Loop(while=<expr>): ..." or something.

Perhaps a future possibility would be syntactic support to adding this kind of context manager to other loops (like somebody above suggested using the "with" keyword) though that might end up with duplicate functionality if the context manager has already implemented features for specific loop like concepts, so that might be something to decide on sooner rather than later...

I'd also use a base class and child classes for the exception because a Boolean doesn't give much scope for distinguishing varieties of flow control conditions and there might be further future additions here (Possibly a retry the current loop option, for example...?)

Python multi-level break and continue

dtlin — Fri, 09 Sep 2022 06:42:55 +0000

Hypothetically, if __enter__ could be a generator, with the with body running for each yielded value, that would give us the power to implement

class Loop:
    def __enter__(self):
        self._do_continue = True
        while self._do_continue:
            self._token = object()
            yield LoopHandle(self._token)

    def __exit__(self, type, value, traceback):
        if type is LoopControlException and value._token is self._token:
            self._do_continue = value._do_continue
            return True

class LoopHandle:
    def __init__(self, token):
        self._token = token

    def break_(self):
        raise LoopControlException(False, self._token)

    def continue_(self):
        raise LoopControlException(True, self._token)

class LoopControlException(Exception):
    def __init__(self, do_continue, token):
        super().__init__()
        self._do_continue = do_continue
        self._token = token

with Loop() as outer:
    with Loop() as inner:
        outer.break_()

I'm undecided whether this is a good thing or not, but it was surprising to me how relatively little it would take to get there.

Python multi-level break and continue

foom — Fri, 09 Sep 2022 04:56:38 +0000

Not that this seems like a good idea but...

A context manager can already handle and optionally catch and suppress exceptions in its __exit__ handler. It cannot, currently, restart execution at the beginning of the 'with' region from __exit__, but that is an easy to imagine addition, which might even be useful for other things, e.g. "with retries(3): do_something_that_might_fail()"

Once you have that simple change, a for_loop context manager is basically implementable. The .break() and .continue() function calls simply throw a special exception type, which the exit handler swallows -- and then either restarts the with region or doesn't. Upon normal exit, the exit handler also determines whether to restart the region based on the loop condition.

Done.

Python multi-level break and continue

mathstuf — Thu, 08 Sep 2022 16:10:24 +0000

What happens with this?

def control_flow_really_should_be_local(loop):
    loop.break()

def i_mean_how_is_this_supposed_to_work(loop):
    loop.continue()

with for_loop(team, conference) as conference_loop:
    with for_loop(player, team) as team_loop:
        if condition:
            control_flow_really_should_be_local(conference_loop)
        else:
            i_mean_how_is_this_supposed_to_work(team_loop)

Python multi-level break and continue

wvaske — Thu, 08 Sep 2022 15:31:00 +0000

I really like the idea of context manager style for loops:

for team in conference as conference_loop:
    for player in team as team_loop:
        if condition:
            conference_loop.break()
        else:
            team_loop.continue()

It's pythonic and makes break and continue much more explicit. Even in normal code without a double break, knowing which iterator a break or continue belongs to would be helpful.

That would take some python internals updating but we could define our own for_loop context manager:

with for_loop(team, conference) as conference_loop:
    with for_loop(player, team) as team_loop:
        if condition:
            conference_loop.break()
        else:
            team_loop.continue()

Python multi-level break and continue

dboddie — Thu, 08 Sep 2022 11:02:19 +0000

Limbo (https://www.vitanuova.com/inferno/papers/limbo.html) also has labelled breaks and continues, though maybe the use case for them in that language is stronger given that break is needed to escape from case (switch) structures. However, it seems that the feature is still useful for nested loops.

In any case, use of labels can help to make the intent clearer in the code, making it explicit which loop is being escaped or continued. In Python you would use a comment for that, perhaps, but you would need to be careful to update it if the code was refactored.

Python multi-level break and continue

Wol — Wed, 07 Sep 2022 19:27:26 +0000

:-)

DataBasic has, I believe, RETURN TO ... , which is probably what you're thinking of ...

I don't believe it is ever used in normal code! Certainly I've never seen it, let alone used it ...

Cheers,
Wol

Python multi-level break and continue

jwilk — Wed, 07 Sep 2022 18:28:44 +0000

Not only bash; "break N" is in POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/utilitie...

Python multi-level break and continue

anton — Wed, 07 Sep 2022 15:39:08 +0000

I don't find anything in "Go to Statement Considered Harmful" that suggests that Dijkstra meant only variants of goto that are more powerful than those in C.

Python multi-level break and continue

NYKevin — Mon, 05 Sep 2022 00:48:05 +0000

> Maybe a "while" clause in the for loop?
>
> [...]

I'm having a hard time seeing how that's supposed to be more readable than just writing break like we do now. Besides, if you really want while-like syntax, you can already write this:

piter = iter(all_player)
while player := next(piter) and not abort:
    # etc.

I just don't see why we need to bolt on an extra clause to the for loop, given that you can just use break instead, or rewrite as a while loop. There are already two ways of doing it, why should we add a third?

Python multi-level break and continue

intelfx — Sun, 04 Sep 2022 23:09:14 +0000

> But I can't think of any language that uses a number of loops to jump out of as an argument to break/continue or next/exit.

Bash?

```
break [n]
Exit from within a for, while, until, or select loop. If n is specified, break n levels. n must be ≥ 1. If n is greater than the number of enclosing loops, all enclosing loops are exited. The return value is 0 unless n is not greater than or equal to 1.
```

Python multi-level break and continue

tialaramex — Sun, 04 Sep 2022 22:59:13 +0000

The interesting unexpected thing I found while researching details of that previous comment was that Rust actually explicitly forbids "break value;" syntax in for and while loops. I had imagined that it was permitted but, because those loops have the empty tuple as their type the only possible value I can break with would be the empty tuple and so I'd get a type error if I tried anything else. But no, I tried it and you can't do this even with the empty tuple as value.

Python multi-level break and continue

neilbrown — Sat, 03 Sep 2022 22:46:11 +0000

I would suggest that "break" and "continue" are the problem rather than the solution, and they should be deprecated. That would, of course, require a somewhat richer looping/conditional construct. I quite like the "Event indicators" described in https://pic.plover.com/knuth-GOTO.pdf (which is well worth reading in its entirity if you haven't already). They are only part of a solution, not a complete design, but I think they point in a good direction.

For a python-like language, I think a flag is the right approach, and if it appears clunky, then that is the fault of the language, and that is where we should look for a fix.

With a c-like for loop, it might appear

   for (piter = all_players.iter(); player = piter.next() ;)
      for (ptiter, abort = all_tables.iter(), False; not abort and player_tables = ptiter.next();)
         for (viter = player_tables.iter(); not abort and version = viter.next();)
              # things  have gone wrong, need to break
		abort = True

	    this_is_not_reached = True

	this_line_is_called()

This is clunky, but not because of the abort (I think) but because you are forced to split the 'init' and 'next' steps of walking the table. Python combines these (good) but doesn't let anything be added (bad).

Maybe a "while" clause in the for loop?

    for player in all_player:
        abort = False
	for player_tables in all_tables while not abort:
	    for version in player_tables while not abort:
		# things have gone wrong, need to break
		abort = True

	    this_is_not_reached = True

	this_line_is_called()

This makes it obvious from the start which loops might abort early. I think it is good to be obvious. With break, it might not be obvious until the end of the loop, which isn't good for readability (unless you keep all loops to 5 lines).
You still have a clunkiness that 'abort' must be initialised before the loop. Maybe this is good as it become trivial to know if the loop aborted.
(of course a good compiler would optimise the flag away and use gotos.)

Python multi-level break and continue

Shugyousha — Sat, 03 Sep 2022 18:19:51 +0000

Golang has labeled "break" and "continue" statements: https://medium.com/golangspec/labels-in-go-4ffd81932339

I don't think I have seen it in production code more than once or twice in ten years of writing Go code. It looked like a code smell then as well ...

Python multi-level break and continue

amarao — Sat, 03 Sep 2022 06:50:00 +0000

I like break 2 approach. If we allow to use values (`break foo`), it can help to write the most hilarious code golf.

Also, I want multi-level return, which forces outer functions immediate return. What a fut it would be!

Python multi-level break and continue

dskoll — Sat, 03 Sep 2022 02:35:12 +0000

If by TCL you mean Ousterhout's Tcl, nope. break does not take an argument and nor does continue. Supplying one gives an error, at least in Tcl 8.6.11.

Python multi-level break and continue

tialaramex — Fri, 02 Sep 2022 11:08:51 +0000

While it's not something you'd put in a slim C-like language, if you have say, closures, then drop replaces the need for the defer feature. You can just build a utility type whose purpose is to run a closure when it is dropped, so then when you make the utility type and specify a closure, it will run that closure when the scope ends, the exact same feature as defer but now just a utility type.

There are (of course) several of these in Rust crates already, suiting different tastes but it's also trivial to build your own instead.

And for state transitions I'd definitely again rather have high level types representing this than try to do it with goto. Pattern matching and sum types make this sort of thing feel very ergonomic to me compared with C. In fact while I understand a C successor isn't going to have Rust's quite sophisticated ControlFlow type, it'd be nice to at least have say <control.h> defining CONTINUE and BREAK so that Library A's maybe_do_stuff() and Library B's repeat_until_done() both agree that CONTINUE is 1 (or 4, or 'Z' I don't care) while BREAK is 0 (or -26, or 5.16, again I don't care) rather than have a situation where Library A signals with -1 while Library B expects 0

Python multi-level break and continue

NYKevin — Fri, 02 Sep 2022 07:23:13 +0000

I would not recommend doing relational querying by hand in Python, for three main reasons:

1. Python is slow.
2. Relational querying by hand implies relational querying in a language other than SQL, which is going to be harder to maintain since SQL is the standard language in this space.
3. Python comes with a bundled copy of SQLite, which has neither of the above problems and is ridiculously easy to set up and use.

Python multi-level break and continue

anselm — Fri, 02 Sep 2022 06:54:51 +0000

Perl has goto mostly because it made the Awk-to-Perl translator easier to implement. It was never recommended for general usage by people in their own programs.

Python multi-level break and continue

excors — Thu, 01 Sep 2022 23:48:37 +0000

I find splitting into smaller functions (just so you can replace the multi-level break with a return) is the optimal solution in maybe 95% of cases. But in the other 5% it can be very awkward, usually because there are several variables shared between the outermost and innermost code and you'd have to explicitly pass them all across the new function boundary (particularly annoying if you've given them nice long descriptive names, which you now have to duplicate into the function definition and the function call), or (even more rarely) because you've already split it once and if you add another function layer then 'return' won't return far enough.

In those cases the code can be simpler and more clearly express the programmer's intent by using a multi-level break instead. They're not very common cases and the workarounds aren't too bad, so it's not a crucial language feature (as demonstrated by the successful languages without it), but it's also not a feature that seems to be widely abused or that causes great confusion (as demonstrated by the successful languages with it), so I think on balance it's still nicer if the language gives you the option.

Python multi-level break and continue

bartoc — Thu, 01 Sep 2022 23:42:17 +0000

Well, you can get something much like rust's drop trait in gnu C (supported in clang as well) using __attribute__((cleanup)) and some macros. This actually ends up working really quite well and makes things much more ergonomic.

In any event I actually want all of goto, defer and drop/RAII. Defer is useful even with drop/RAII when you are interfacing with external code or doing something "one off". Goto remains useful for implementing certain algorithms involving state machines and tables.

While not super useful in combination with goto there is a related gcc extension called "labels as values" that I really wish would be standardized, since it allows writing code that would be almost impossible otherwise (like tracepoints).

Python multi-level break and continue

NYKevin — Thu, 01 Sep 2022 23:36:58 +0000

> You just have to put all of your code in main, and then C's goto is functionally identical to the original goto.

For people with no sense of humor: This is a joke. Do not actually do this.

Python multi-level break and continue

NYKevin — Thu, 01 Sep 2022 23:35:37 +0000

Strictly speaking, you can recover the goto that Dijkstra was talking about very easily in C. You just have to put all of your code in main, and then C's goto is functionally identical to the original goto.

> For the cleanup problem, I think C successors tend to offer defer here for that purpose. I don't like defer, but it's a more healthy solution than goto fail: type arrangements. I prefer something like Rust's Drop trait but I can see that feels too much like invisible magic for some C practitioners.

People have come up with many, many different solutions to the cleanup problem:

* try-with-resources (Java)
* with/using statements (Python/C#)
* defer (Go)
* Destructors (C++, Rust)
* finally (just about any language that supports exceptions, including several of the above)
* Higher-order functions like Haskell's withFile
* Optional types (which allow you to coalesce the happy path with the unhappy path so that you only have one code path and don't need to "handle" cleanup specially)

Most of these options would require C to grow something vaguely resembling nontrivial data types (what C++ would call non-POD types), which will obviously never happen, but defer would make logical sense for C, IMHO. You could also make an argument for finally, because even without exceptions, it still intercepts early returns (as well as more convoluted nonsense like break and continue, and one imagines it could also do goto).

Python multi-level break and continue

tialaramex — Thu, 01 Sep 2022 23:12:18 +0000

Right, Dijkstra's ketter is about the go-to feature as manifested at that time which is way more powerful (and thus dangerous) than anything mainstream languages support today. Dijkstra is arguing for what we have today, loops, procedure calls, structured control flow rather than just jumping around.

For the cleanup problem, I think C successors tend to offer defer here for that purpose. I don't like defer, but it's a more healthy solution than goto fail: type arrangements. I prefer something like Rust's Drop trait but I can see that feels too much like invisible magic for some C practitioners.

Python multi-level break and continue

dtlin — Thu, 01 Sep 2022 22:26:43 +0000

break value is valid for loop. There's no other possible value for a loop expression, but a for/while loops can terminate normally, so it doesn't make sense to break value there.

To be clear though, what I was talking about is

'outer: loop {
    'inner: loop {
        break 'outer;
    }
}

where break 'label escapes both loops. This can be combined, e.g. break 'label value.

Python multi-level break and continue

Wol — Thu, 01 Sep 2022 21:41:45 +0000

> the whole query planner/optimizer/code generator of a database.

of a *RELATIONAL* database.

Pick does not have a query planner - the optimal plan is "do as you're told".

Pick does not have an optimiser - okay, it's down to the user to make sure all your indices are properly declared, but in a well-designed database there is nothing to optimise.

Pick does have a compiler, but the object code lives in the database and is compiled at development time, not run time.

And the same is true for most other non-relational databases I would think. Hierarchical databases are mostly drill-down and optimised for fast access along common paths. Pick takes that to the next level - it's drill-down and optimised for fast access along any *sensible* path.

Cheers,
Wol

Python multi-level break and continue

bartoc — Thu, 01 Sep 2022 21:00:31 +0000

Strongly agree with this take. If you aren't going to reuse it then it's usually not worth splitting stuff out it's own function. Just let me read the darn code. If the function is doing some well known algorithm maybe it _is_ worth it, but even then sometimes a comment is just as good as a function.

Keeping things inline can make optimization opportunities more clear and make anti-optimizations stick out more, as well.

Python multi-level break and continue

bartoc — Thu, 01 Sep 2022 20:44:54 +0000

The complaint about "trying to do ad-hoc relational querying with imperative code" is particularly frustrating because that's a great example of an algorithm that this stuff makes easier! There's nothing wrong with writing out your "relational queries" instead of going through the whole query planner/optimizer/code generator of a database.

Python multi-level break and continue

bartoc — Thu, 01 Sep 2022 20:39:34 +0000

C goto can not jump deeper (or shallower) in the callstack. It's a local goto.

It can jump "down" through a function though which sounds scary but in reality it's almost always used for jumping to cleanup code.

C goto is not the goto that Dijkstra was railing against, and is basically fine.

This whole discussion is honestly one of my biggest annoyances with the python community, it's pretty clear a lot of the code examples were being compared on just "personal preference", not any real concept of maintainability.

Python multi-level break and continue

edeloget — Thu, 01 Sep 2022 18:33:30 +0000

Ouch. My head hurts.

Frankly, in the name of readability, this looks like a very good candidate for modularisation. Your inner loop is exiled in a function that returns a specific value when it "break", and this function is called by the outer loop (which can then break if it receive said specific value when it calls it).

This has many other advantages, such as:

* not melting the mind of people who are reading your code ;
* open yourself to reuse of the inner loop
* not needing to change the whole language to support a feature that will only make you sad and angry in the long run.

And if you are using a compiled language, there is a good chance that it will be able to optimize something (and if you're not using a compiled language then the additional time it would take to evaluate an additional function is not really an issue).

Python multi-level break and continue

k8to — Thu, 01 Sep 2022 16:35:40 +0000

TCL does the break 2 thing. Unfortunately.

Python multi-level break and continue

rgmoore — Thu, 01 Sep 2022 16:31:09 +0000

Perl's next and last constructs only work with loop labels, but it does have a goto statement that can jump to just about anywhere you tell it. Loop labels are one of those things people use when they feel they have to, but I don't think I've ever seen anyone use an actual goto.

Exceptions

k8to — Thu, 01 Sep 2022 16:30:30 +0000

The reasons to avoid exceptions don't really exist in python. They arent dangerous or slower than other options. They're just anothe control flow that work well cor problems but are fine for other bailout scenarios.

They would be awkward if you had a need to jump out to a variety of levels but i have difficulty imagining a usecase for that.

Python multi-level break and continue

JoeBuck — Thu, 01 Sep 2022 15:53:02 +0000

Multi-level break/continue with a loop label is part of Ada, VHDL, and Perl; all three spell 'continue' as 'next'; Ada and VHDL say 'exit' instead of 'break' and Perl says 'last'. Verilog has 'disable' which can be used to jump out of any labeled statement (which might be a loop or a begin/end block). But all of these rely on attaching a label to the region of code in question, so it's stable as the code is maintained (and perhaps extra loops are added).

But I can't think of any language that uses a number of loops to jump out of as an argument to break/continue or next/exit.

So if it's done I think the label approach should be used.

Python multi-level break and continue

flussence — Thu, 01 Sep 2022 14:42:28 +0000

Where Perl's label construct differs from a C goto is that Perl's can only jump laterally or upwards; a C goto can jump deeper into the call stack or to unrelated code, with all the headaches that can cause. This version of goto/continue/break is more like throwing and catching an exception - in Raku they're actually implemented as a special case of those.

I think it'd be a good solution to Python's problem. I've used numbered breaks in PHP code and can't say it was much good for maintainability.

Python multi-level break and continue

mathstuf — Thu, 01 Sep 2022 13:32:03 +0000

I've been thinking about when I've seen (or done) it. It's usually in C or C++ where I want to break from a loop from within a `switch`. `continue` works, but `break` is unfortunately overloaded. So much would have been better if fallthrough were not an implicit thing there… But Python doesn't have that problem, so I don't think there's much value here in it for Python.

Python multi-level break and continue

eru — Thu, 01 Sep 2022 12:42:16 +0000

Splitting code into smaller functions is often good practice, but not always. I often find it clearer to have the whole inline, so it can be seen at a glance, instead of lots of small functions used only once. The latter is like reading a text that keeps jumping into footnotes!

As a contribution to the fun syntax bikeshedding, a language I was involved in implementing had a loop roughly like this:

while cond1
    while cond2
    ...
    // Want to break out of both loop levels?
    if satisfied
        break foundIt
   endwhile
endwhile foundIt

The break is a jump forward, so it makes sense the label is at the endwhile. Of course this wont work too well in Python that lacks a delimiter to mark the end of the loop, other than decreasing indentation.

Python multi-level break and continue

Wol — Thu, 01 Sep 2022 12:32:47 +0000

I believe DataBASIC has the labeled loop approach ... (but not the version I saw here)

FOR I = 1 TO 10
...
CONTINUE I_WANT_OUT:
...
I_WANT_OUT: NEXT

It's a syntax error if the continue refers to a line-label that is not a valid loop terminator. Makes it dead easy to see where you are jumping to.

Cheers,
Wol