Working around a lack of 'goto' in python

[Jeff Epler]

[Mr. Binns helpfully deleted the attribution, so I didn't even realize
right away he was replying to my post]

Jeff Epler wrote:
> > Look, a bug!
> >
> > With this "feature", you have to scan the entire body of the loop
> > looking for a numeric break/continue if you're going to change the
> > indentation level, then increment or decrement the number.
> 
On Mon, Mar 08, 2004 at 01:14:05PM -0800, Roger Binns wrote:
> Yes, but you can screw up any code when adding loops.

I wonder why I never remember being bitten by the bug you describe.
Maybe I rarely write code which requires the later addition of a
nested loop (something that would apply equally to today's "break" and
"numbered break").  Maybe I sort it out (but there's no guarantee I'm
smart enough to sort out a slightly more complex scheme).  Or maybe I
run into this all the time, stuggle to re-write the code within Python's
limitations, and then forget about it before the next time it happens.
Anyway, I'll remain firmly in the "don't need it" camp, while admitting
that my earlier example was poorly thought-out.

Interesting fact of the day: statistics from the library files included
with python2.2 (/usr/lib/python2.2/*.py):

Occurrences of "while" or "for": 2357
Occurrences of "continue" or "break": 526

(Using "egrep -w", so the words in comments or strings count towards the
total)

A minority of loops have a single continue or break.  Wouldn't it be an
extreme minority that are nested, need multi-level break, and aren't
expressed about as well in one of the other forms? (iterators being my
favorite, and exceptions being my least favorite)

As further evidence (either of the BDFL's bias, or the lack of need for
it) I offer the fact that list comprehensions and now generator
expressions don't have "break"/"continue" logic.  I have seen one call
for [g(x) for x in l while f(x)].  Currently this can be done with
itertools.takewhile(), but the BDFL has already decreed once that he'd
like to see listcomps and generator expressions replace map()/filter(),
so I'm a little surprised he accepted itertools.  Will itertools be
deprecated with the creation of generator expressions?

Jeff