Working around a lack of 'goto' in python
kkto at csis.hku.hk
Wed Mar 10 06:16:12 CET 2004
>>>>> "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,
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.
More information about the Python-list