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.
[ Parent
| on HN ]
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.