Greetings list, I wonder if the issue should be named as: introduce absolute break in Python as if you have 5 nested loops (which you probably should not), breaking loop_i won't do anything Kind Regards, Abdur-Rahmaan Janhangeer about https://compileralchemy.github.io/ | blog https://abdur-rahmaanj.github.io/ github https://github.com/Abdur-RahmaanJ Mauritius

I personally am +1 for something like this. What about for use with `continue` as well? e.g.

for i in range(10) as i_loop: for j in range(i, i + 10) as j_loop: if i + j == 9: continue i_loop

which will break out of j_loop and go to the next i (as if the `continue` statement were used)

Hello, On Thu, 03 Dec 2020 11:06:41 -0000 "Jonatan " wrote:

Hi, sometimes I do nested loops and I want to break specific loop, outer/inner etc. I need to do an ugly thing with for..else and it's annoying.

It'd be nice if we could do so: for i in range(10) as loop_i: for j in range(i, i + 10) as loop_j: if i + j == 9: break loop_i or something like this. Please comment what do you think about this idea.

Funnily enough, this was mentioned just yesterday on a quite not directly related thread, https://github.com/WebAssembly/design/issues/796#issuecomment-737244573 . As it points out, it's PEP 3136 https://www.python.org/dev/peps/pep-3136/ , proudly bearing the badge of "Rejected". And the rejection is likely right than wrong - why patch-up language with adhoc stuff to break thru loops, if the language already offers means to break thru *absolutely any levels of anything*, including nested function calls. It's try/raise, please enjoy its usage for this purpose too, like other people do already. -- Best regards, Paul mailto:pmiscml@gmail.com

On Fri, Dec 4, 2020 at 12:25 AM Jonathan Fine wrote:

Hi Jonatan

Please consider for a in aaa: for b in bbb: if condition(a, b): break KEYWORD: break where KEYWORD is like else, but with the opposite semantics. I think this does exactly what you asked for, in your example.

well... uhhh.... Technically you can do that already.... for a in aaa: for b in bbb: if condition(a, b): break else: continue # We didn't break from b, so continue a break # We did break b, so break a But I don't think anyone's actually doing that :) ChrisA

03.12.20 15:59, Chris Angelico пише:

well... uhhh.... Technically you can do that already....

for a in aaa: for b in bbb: if condition(a, b): break else: continue # We didn't break from b, so continue a break # We did break b, so break a

But I don't think anyone's actually doing that :)

I did. :( In cases when functions or generators add significant overhead.

I think this is the kind of feature that can very easily be abused. Whenever I want to break out of a nested loop I take this as an opportunity to extract the loop into its own function and use the return statement to break out of the loop. IMO this is a lot better than having named or indexed loop control because a proper function can later be reusable, and it lets you explain why you need to return early in the docstring.

Just want to say that that is brilliant, and I would have not thought of that, that's a cool idea! Only annoyance is that it introduces an indentation, otherwise it'd be perfect! On Mon, 7 Dec 2020 at 23:30, Daniel Moisset wrote:

For the likely rare situation where I'd want to do this rather than refactoring into a function, I might try with something like this without requiring changes to the language:

from contextlib import contextmanager

@contextmanager def breakable(): class Break(Exception): pass def breaker(): raise Break try: yield breaker except Break: pass

This allows defining a block that can be "aborted" (which can have a loop or any other statement block within); you abort it by calling the resulting value of the context manager. An example of use is available at https://gist.github.com/dmoisset/55f5916f9f339a143b6f3d155de8706e

On Thu, 3 Dec 2020 at 11:07, Jonatan wrote:

...

Hi, sometimes I do nested loops and I want to break specific loop, outer/inner etc. I need to do an ugly thing with for..else and it's annoying.

It'd be nice if we could do so: for i in range(10) as loop_i: for j in range(i, i + 10) as loop_j: if i + j == 9: break loop_i or something like this. Please comment what do you think about this idea. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/55E2WX... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VY4KQN... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Dec 7, 2020 at 6:27 PM Daniel Moisset wrote:

For the likely rare situation where I'd want to do this rather than refactoring into a function, I might try with something like this without requiring changes to the language:

from contextlib import contextmanager

@contextmanager def breakable(): class Break(Exception): pass def breaker(): raise Break try: yield breaker except Break: pass

This allows defining a block that can be "aborted" (which can have a loop or any other statement block within); you abort it by calling the resulting value of the context manager. An example of use is available at https://gist.github.com/dmoisset/55f5916f9f339a143b6f3d155de8706e

I agree with the person who called this a brilliant solution. Here is the code from the link for completeness: for outer in range(5): with breakable() as brk: for middle in range(5): for inner in range(10): print(outer, middle, inner) if middle == 1 and inner == 5: brk() print(f"end middle loop #{middle}") print(f"end outer loop #{outer}") print("done") Iterating on that idea a bit and taking advantage of the walrus, what if syntax were created allowing us to remove the extra indentation level, and also allowing us to contextualize any loop without having to employ the with statement? I imagine is looking something like this: for outer in range(5): @breakable for middle in loopX := range(5): for inner in range(10): print(outer, middle, inner) if middle == 1 and inner == 5: loopX.brk() print(f"end middle loop #{middle}") print(f"end outer loop #{outer}") print("done") Above, breakable will be some decorator that returns a context manager, and the "loopX" loop happens in the context of that context manager (with the name "loopX" assigned to the context object). Here is some more detail about what I am imagining happening with this new syntax: 1. the name `loopX` is assigned to the iterable in the for statement, as usual 2. the first time the for statement ` for middle in loopX := range(5): ` is interpreted/excuted, the presence of the decorator causes this to happen before iteration starts: loopX = breakable(loopX) with loopX as loopX: for middle in loopX := range(5): # the "loopX" loop is now executed within the loopX context 3. the utility of this syntax would not be limited to the breaking of named loops. with this syntax in place, one could write any kind of context manager they want for contextualizing the execution of loops (both for loops and while loops). 4. last note: if no name is supplied to the iterable object using the walrus, then applying the decorator to the loop would be a syntax error What do you think? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler http://python.org/psf/codeofconduct/

On Tue, Dec 8, 2020 at 3:31 PM Ricky Teachey wrote:

...

I agree with the person who called this a brilliant solution. Here is the code from the link for completeness:

I'm not diss'ing the approach. But it doesn't really save that much over a sentinel variable `break_to_middle`. And if you wanted to break to any of several levels from the innermost, you'd need multiple context managers.

...

Fair enough. For me the "brilliance" comes in how readable it comes out to be; I find it far easier to scan through and understand (without even looking at the brk() function to see what it does) the first time through

On Tue, Dec 8, 2020 at 10:42 AM David Mertz wrote: then the sentinel approach. My syntax suggestion came from thinking about how to make it even more readable (providing one can swallow the "this decorator automatically becomes a context manager" part-- which might be too hard to swallow I don't know). --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler