break and continue could have arguments, that determine from which loop (starting counting from the loop where break is to out) program should break out or take new value for variable.
for i1 in range(3):
for i2 in range(3):
for i3 in range(3):
print(i1,i2,i3)
if i1==i2==i3:
break(1)
This is very fragile. Consider your second example:
for i1 in range(3):
for i2 in range(3):
for i3 in range(3):
print(i1,i2,i3)
if i1==i2==i3:
break(2)
Suppose I insert another loop (not as uncommon as you might think). Now
I must renumber all the breaks inside the loop.
A less fragile approach would be labels, something like this:
PRIMARY:
for i1 in range(3):
SECONDARY:
for i2 in range(3):
INNERMOST:
for i3 in range(3):
print(i1,i2,i3)
if i1==i2==i3:
break(SECONDARY)
Ignoring that this particular syntax doesn’t quite fit Python, now the
loop you intend to break from has a stable name which adding more
structure such as an additional loop will not change. Perl’s got
something like this.
In this particular case, the use of itertools’ product and takewhile
would result in more readable code than nested loops. For more complex
cases, one should move the inner loops out to a separate funtion
and return from it.
IMHO breaking outter block, if ever accepted into Python, should base
on names instead of number. We could use a new keyword e.g. block RABBIT:
which both to name it for breaking and introducing a new lexical scope.
While we’re at it, why not go ahead and add goto as well (-;
In other words, this seems to be nice-to-have, but seems to conflict
with the Zen of Python:
Simple is better than complex.
Flat is better than nested.
There should be one-- and preferably only one --obvious way to do it.
Agree.
But maybe these ways are not equal, maybe the 1 with break(3), could be compiled to run faster than the solution with flag, because checking flag for every new value of i2 and i1 takes time.
Pycharm or other idea could do it automatically after new loop has been added.
It does not work with every program. Following programm
n=0
for i3 in range(n):
for i2 in range(n):
for i1 in range(n):
if F(i1,i2,i3)>0:
break(2)
if F(i1,i2,i3)>1:
break(3)
if F(i1,i2,i3)>2:
continue(2)
if F(i1,i2,i3)>3:
continue(3)
n+=F(i1,i2,i3)
n+=F(i3,i2)
n+=F(i3)
is very hard and ugly without using flags, function calls, break with argument or continue with argument.
Addition to my idea: argument of break would count every statement that causes indent (if,try,else,except,finally,with). So it could be used to break out from other blocks as well.
I think the reason why current version break does not break if’s is that it can break only 1 block and if’s would stay on way and not let to break loop-blocks.
while True:
x=A(x)
while True:
x=B(x)
while True:
x=C(x)
if x>2:
break(3)#goto x=A(x)
if x>1:
break(2)#goto x=B(x)
if x>0:
break(1)#goto x=C(x)
else:
return(x)
´´´
Well found, Dennis. I would also note GvR’s comments in the rejection of this idea:
“code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code”
and
“this has been brought up and rejected many times before”
and
“My expectation that the feature will be abused more than it will be used right”
and (my favourite)
“There is real value in having a small language”
break and continue are statement keywords. They are both specialized goto statements. They cannot be turned into functions without breaking every current use. Nor could they work to jump as functions. But they could be extended with new fields: break <N> or`break
What you mean by “breaking current use”? If it would be possible to pass them arguments (that would determine where to goto) and without arguments they would do same as they do in current version, it would not make the new version incompatible with current one.