| msg200603 - (view) |
Author: James Lu (James.Lu) * |
Date: 2013-10-20 18:19 |
| 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. |
|
|
| msg200605 - (view) |
Author: James Lu (James.Lu) * |
Date: 2013-10-20 18:27 |
| 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! |
|
|
| msg200609 - (view) |
Author: Martin Matusiak (numerodix) * |
Date: 2013-10-20 18:36 |
| 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. |
|
|
| msg200610 - (view) |
Author: James Lu (James.Lu) * |
Date: 2013-10-20 18:40 |
| 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> > _______________________________________ > |
|
|
| msg200611 - (view) |
Author: James Lu (James.Lu) * |
Date: 2013-10-20 18:43 |
| 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! |
|
|
| msg200612 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2013-10-20 18:50 |
| 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. |
|
|
| msg200613 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *  |
Date: 2013-10-20 18:55 |
| 'continue' also should support this feature. |
|
|
| msg200614 - (view) |
Author: James Lu (James.Lu) * |
Date: 2013-10-20 18:57 |
| Oh, yes,yes,yes! |
|
|
| msg200616 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2013-10-20 19:06 |
| 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 :-)) |
|
|
| msg200687 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2013-10-21 02:57 |
| 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. |
|
|