Working around a lack of 'goto' in python

[Isaac To]

>>>>> "Stephen" == Stephen Horne <steve at ninereeds.fsnet.co.uk> writes:

    Stephen> As a rule, having a program that runs a few milliseconds slower
    Stephen> is preferable to having a maintenance headache. The reason why
    Stephen> gotos, breaks and continues are considered bad style in any
    Stephen> language is because when used inappropriately they routinely do
    Stephen> create maintenance headaches, and because the temptation is to
    Stephen> use them inappropriately.

Everything said above is true for most programming constructs.  You can put
"local variables", "global variables", "dynamic scoping", "functions",
"classes", "exceptions", "checked exceptions", etc., into the above
paragraph, and the paragraph still "make sense".  The worth of a programming
construct is how *good* it is when it is used *appropriately*, not how *bad*
it is when it is used *inappropriately*.

    Stephen> As I mentioned elsewhere, I have used gotos recently but only
    Stephen> once in ten years or so. I have no doubt that there are many
    Stephen> simpler cases where at some time I could have avoided a state
    Stephen> variable or an exception by using a goto, but following a
    Stephen> standard convention has some value in itself and these days the
    Stephen> standard convention is to use a state variable or an exception.

One can likewise use goto in a "standard convention", and indeed that is
what I always do: just like any other person, I fully acknowledge that goto
is horrible when used inappropriately.  But the same can be said to, say,
classes.

    Stephen> These are relatively unusual cases, though. Certainly they pop
    Stephen> up from time to time, but in the mean time you've probably
    Stephen> written tens of loops that didn't need these tricks.

Most people *fear* goto.  They think that "if I use goto, my program is
unclean".  Or "if I use goto now, my program won't be readable tomorrow".
Or simply, "my manager is going to blame me the moment I show my program to
him just because I use goto".  But even though we are under such climate,
once in a while we find that goto actually clean up mess.  I think this
alone means that we should look at the construct again to see whether we
are too critical to it from the beginning.

Of course, this is from the user's point of view.  From the implementation
point of view, that can be another story: one won't want constructs that are
too expensive to implement.  Unconditional jump will remove some
optimization opportunities.  But it is "paid only by those who use it", so I
think it is a fair deal.

Regards,
Isaac.