Daniel wrote: > And I have to keep the code simple for non CS people to run > the actual experiment.
Do you think the software in the Apple iPod is "simple"? Or Microsoft Windows? No. You need to keep the *interface* simple. The internal details can be as complicated as they are needed to be. Same applies to your data acquisition application. Unless you expect these non-CS people to be hacking the source code, they only interact with the interface, not the internals. Earlier, back in your initial post, you said: "I don't see any way to reduce these nested loops logically, they describe pretty well what the software has to do. This is a data acquisition application, so on ever line there is a lot of IO that might fail or make subsequent steps useless or require a retry." Do you think you're the first person to have written a data acquisition application in Python? Almost certainly you can simplify the structure of the code by splitting it into functions appropriately, instead of the spaghetti code you have (apparently) written with jumps all over the place. To take the most obvious, simple example: any time you have a loop that you might want to redo, the right solution is to put the loop inside a function, and then "redo the loop" becomes "call the function again". I suppose that, just possibly, your application really would benefit from named labels to jump to. But if so, you've stumbled across something rarer than iridium. -- Steven -- http://mail.python.org/mailman/listinfo/python-list