News for hackers. Stuff that matters.
Re:A function decorator that rewrites the bytecode to enable... by noduerme on Tuesday September 21, 2021 @04:46AM (#28603144)
In a situation like that I would usually define a boolean before entering the top loop, and set that true within once a condition is met, causing all the outer loops to break if that condition is true. I can't imagine there would be a major speed difference in some other way of breaking all the loops to jump to a different line of code.
Re:A function decorator that rewrites the bytecode to enable... by withinboredom on Tuesday September 21, 2021 @05:29AM (#28603347)
That means once it’s set to true, all the inner loops would need to at least finish that iteration. That could be a huge speed difference at a minimum or a completely wrong implementation.
Re:A function decorator that rewrites the bytecode to enable... by simion314 on Tuesday September 21, 2021 @05:40AM (#28603399)
this means you do a if check each loop, this is bad if you do some say image filter/effect where you work with big loops. end you get some nested if and break inside the code, is much more readable to just jump out.
Re:A function decorator that rewrites the bytecode to enable... by Dylan16807 on Tuesday September 21, 2021 @06:48AM (#28603724)
I would argue that having to do that is not in fact a 'proper' loop. Your way and goto are both workarounds for a missing control flow construct.

For gosub, what's the issue? It is a method call.

Re:A function decorator that rewrites the bytecode to enable... by slightwinder on Tuesday September 21, 2021 @10:05AM (#28605119)
Pythons for-loop is not working with boolean, so using one would mean to uglify the code. A goto would simplify the workflow by removing 1-2 lines for each additional loop.