break 2 would break out of one loop then break out of another.
break
break
would just break once and not execute the second break.
break 2 when there are only 1 thing to break would raise raise a SyntaxError: Can only break 1 time, need to break 2 times.

You would have to do this:
for i in range(1,10):
    broke = True 
    for x in range(2,5):
        break
    else:
        broke = False
    if broke:
       break
to break twice, and you can't break only once!

I see one potential problem with this, namely that refactoring code that contains "break n" statements would become more error prone whenever the depth of the code block gets modified. So if you had something like:

for i in range(10):
    for j in range(10):
        for k in range(10):
            if cond:
                break 2

And then you decided to remove the middle loop (on j), the break 2 would send you to the top level, whereas you might have meant for it to break to the first level, inside the loop on i.

This is a micro example, of course, but if you imagine the bodies of these loops being quite long then it could get complicated fast.

Big example:
pygame, event proccessing loop running. the user clicks "Quit", you do
break 2.
psuedocode:
while True:
    for event in pygame.events.get():
        if event.type==pygame.QUIT:
            break 2

james

On Sun, Oct 20, 2013 at 2:36 PM, Martin Matusiak <report@bugs.python.org>wrote:

>
> Martin Matusiak added the comment:
>
> I see one potential problem with this, namely that refactoring code that
> contains "break n" statements would become more error prone whenever the
> depth of the code block gets modified. So if you had something like:
>
> for i in range(10):
>     for j in range(10):
>         for k in range(10):
>             if cond:
>                 break 2
>
> And then you decided to remove the middle loop (on j), the break 2 would
> send you to the top level, whereas you might have meant for it to break to
> the first level, inside the loop on i.
>
> This is a micro example, of course, but if you imagine the bodies of these
> loops being quite long then it could get complicated fast.
>
> ----------
> components: +Interpreter Core
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue19318>
> _______________________________________
>

Every new feature takes on new challenges and harder ways to debug.
But what about using that very confusing code that I showed that only let's you break one amount, that would be harder to debug!

I suggest that there is a zero chance of this being actioned unless the OP wants to do all of the work and attach all of the required patches to this issue.

'continue' also should support this feature.

Oh, yes,yes,yes!

Language ideas such as this are best discussed on the python-ideas mailing-list:
https://mail.python.org/mailman/listinfo/python-ideas

(note that IMO this particular one has very little chance to succeed :-))

FWIW, the usual ways to handle the double-break problem are:

* check a flag variable in the outer loop

* put the outer loop and inner loop in a function so that a return-statement can be used to exit both loops

* enclose the outer-loop in a try/except, then raise an exception to end the inner-loop

Your multi-break idea isn't crazy.  IIRC, Knuth discussed the idea (along with others such as labeled breaks) in one of his influential papers on structure programmiing.  That said, the idea didn't catch on and most people seem to be able to live easily without it.