Working around a lack of 'goto' in python

benjamin schollnick bscholln at mac.com
Sun Mar 7 22:38:24 EST 2004


In article <71tm409egnua4ncic1siadnk7fi9rqnp8e at 4ax.com>, Stephen Horne
<steve at ninereeds.fsnet.co.uk> wrote:

> If you say so. But in reality, but returning a function pointer to a
> function that is immediately going to call that function pointer,
> you're basically just faking the effect of a goto anyway.
> 
> Implementing a state machine using gotos (in those extremely rare
> cases where it is an option) does not damage readability or
> maintainability. Implementing a transition as 'return statefn;' or as

That really depends...

Goto's do have their places, and as I say, everything in moderation.

If you use Goto's, do yourself a big favor, and DOCUMENT... DOCUMENT,
and DOCUMENT!

The significant difference that I believe your forgetting is simply,
using a "switchboard" function or module, allows you to clearly have
a defined start, and end position in the code...

What do I mean?  (If I wasn't clear)

Using a function call, and a return statement (or just a implied return)
allows you to know *immediately* where the code will return to.  (The
next statement after the function call)

A goto jump to somewhere else in the code, will take you to the "jump
point", but where will you return to?

You then have to parse the function and find out where you are going to
go next.  There is no clear structure.

This has it's advantages, but I feel that the disadvantages out weight
the advantages...

It may be a little bit more work to find a better way to code around
the need for a goto.  But, it will force you to write cleaner code.

If you can not find a alternative to a GOTO statement, you may need to
re-examine your concept/structure, and see if there is a alternative
structure that you may have missed.

         - Benjamin



More information about the Python-list mailing list