Working around a lack of 'goto' in python

Stephen Horne steve at
Mon Mar 8 03:54:38 CET 2004

On Sun, 07 Mar 2004 15:49:07 -0500, Roy Smith <roy at> wrote:

>In some respects, you're right.  Certainly, both ways get you the same 
>pseudo-random flow of control, but that's inherent in a state machine.  
>What the function-per-state approach gets you is modularity.  Each 
>function at least has its own namespace and set of local variables. 

This is actually pretty much the point. The function involved is only
sufficiently complex to warrant unit tests when taken as a whole. The
processing within a state could be compared with the inner loop of,
say, an strcpy. A little more complex, but only a little.

The total number of states is pretty small, 6 in total, with the
awkwardness of a non-state-based approach resulting entirely from the
arrangement of transitions. And as I said, it is what I call 'short
running' - the whole thing runs to completion in probably a few
hundred cycles for typical cases.

If the states had a significant amount of code I'd agree with you, but
as it stands it is easier and more useful to write the unit tests for
that one function.

I just wish I had the example ten years ago, when I suggested the
exactly this pattern as a potential justification for gotos to a
college lecturer but couldn't think of a use case. It's so unfair that
I don't get to say 'told you so, told you so, nur nur na-nur nur' :-)

Anyway, the point is, no - I'm not nuts. Honest. Well, I am, but not
about this. It's just a bizarre special case, interesting only as...
well, not even interesting really I suppose - I'm just bored.

Steve Horne

steve at ninereeds dot fsnet dot co dot uk

More information about the Python-list mailing list