On Mar 11, 2:30 pm, Lie <[EMAIL PROTECTED]> wrote: > On Mar 12, 12:00 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > > Actually, the latter is even less cluttered, misses a raise - if pure number > > of literals is your metric, that is. > > You don't just compare by the calling code, you've got to compare also > by the surrounding codes. The calling codes in SE might be a little > bit messy, but it worths by making the code surrounding it more clean > and structured. And anyway, if you used Context Object callback, they > will be as messy as each other. > > > You didn't understand my example. If there is a handler registered, it will > > be invoked. If not, nothing will be raised. The exact same amount of > > state-keeping and lookups needs to be done by the SE-implementation. > > I do understand your example. And even if I misunderstood you about > passing context object, the same problem still exists in context > object based solution, i.e. functions can't make the called function > break automatically, it must be 'break' manually or the program will > go astray (break ==> return, sorry I confused it with break for > loops). And if you used InterruptException to break, it doesn't play > well with multiple SoftExceptions.
Are you interested in yielding an object? In situ, a routine has extra information it wants to return to the caller. Can you protocol a number of yields? Discard x for x in operation()[:3]; x= operation(). Or, x= operation()[3], and go back and look operation() [1], which is cached. -- http://mail.python.org/mailman/listinfo/python-list
