Control of flow

[Alex Martelli]

"Campbell" <cb921 at voice.co.za> wrote in message
news:Pine.LNX.4.31.0107311707320.4442-100000 at cb921.local...
    ...
> >What are the conditions under which you want to repeat
> >this inner loop (letting the user enter a day for the
> >fixed month) rather than redo the outer loop (letting
> >the user enter the month again)?
>
> In this case I'd like to keep the caller in the inner (day) loop,
> entering '#' cound be checked to go to the outer loop, but I use
> constructs like this for many things.  Sometimes a caller will enter the
> begin and end of a range, and which loop to jump into could depend on
> what specific error condition was noticed.

Exactly because you use such constructs frequently, you
should embody them into functions (or possibly classes,
but that doesn't seem to give much added value here) and
use exceptions to signal "out-of-band" when needed.  Do
remember an exception is an instance like any other and
is quite capable of carrying extra auxiliary information.

> I've made something exactly
> this ugly (except which worked) twice today already, and this is what it
> all gets to look like?  Every time I do it, I think to myself, that it
> is rare unless I'm handling this kind of input, where values are
> available one at a time, and I must respond with prompts correctly.
> Following which is the thought: "that sort of input is kind of
> common around this place..."

So it's not rare for you, so you should spend a little
bit more effort ONCE to get a nice reusable framework
(functions & exception classes) for your purposes.

> Here is where Perl's name-able loops are remembered with fondness.
> (but Perl by nature just isn't maintainable of course ;-)

Sure, but I wouldn't mind an ability to name loops, either.
It's hardly crucial, but it IS handy at times (Java has
them, too).

> >that's not too bad for a couple of entries, but it
> >gets slightly tiresome when you have a zillion.  That
> >is (part of:-) what exceptions are for...
>
> thank you... I could make an interesting while 1: with a try: inside of
> it handling custom exceptions, and in each except: could have the
> retry/continue stuff.  Still, for the common situation where context
> differs and 'error' conditions that are checked for vary, it seems like
> a bit of overkill.  It's not that I mind doing it, it's at least
> 'elegant' while my cont variables are not, I just mind having to explain
> that to the workers :)

Overkill?  Yes, if the need is infrequent, but, if frequent, then no.
Python makes it quite easy for you to build in just the amount of
flexibility you need by passing in functions or other callables,
for example.


> I'm trying to replace a commercial telephony platform with something I
> hacked together with swig and Py, on which many different applications
> share the server, each with it's own number.  So far it's going very
> well, the only Gripe I have ever heard from others (or had myself)  has
> been this.  So I shouldn't whine too loud, Python really has changed my
> world for the better. :)

But you can remove this specific "gripe" too, quite easily...


Alex