Neil Cerutti wrote: > On 2006-12-01, robert <[EMAIL PROTECTED]> wrote: >> Ben Finney wrote: >>> robert <[EMAIL PROTECTED]> writes: >>> >>>> Carl Banks wrote: >>>>> 2. Consider whether you're unwittingly trying to cover up a bug. >>>>> ISTM no matter how problematic the input is, you should at least >>>>> be able to make progress on it. Are you getting this error >>>>> because, say, you're not incrementing a counter somewhere, and >>>>> thus recalling a function with the same arguments again? >>>> the "bug" comes in from the I/O input. >>> If a program doesn't gracefully deal with bad input, that's a bug in >>> the program. You should be designing your input handler so that it >>> will do something helpful (even if that's to stop immediately with an >>> informative error message) in the event of bad input, rather than >>> allowing that bad data to send your program into an endless loop. >> >> Yet that detection is what the asked alg should do. Example: >> When a HTML-(content)-relaying sends you around in a circle >> through a complex handler chain. > > Being in a cycle doesn't actually prove your program will never > halt for that particular input, does it?
not. but its not about a theoretical prove. in practice with same state it goes through the same function here.. I had simply had situations where a server looped my client on to a Python (long through a couple of func-calls) recursion error . thus, either I fiddle a recursion/counter parameter through my calls, or I do complex state detection as e.g. to copy that of cherrypy was recommend in other post. Or: I simply throw a hammer at an n-th recursion, wereby I programm the counter locally as simple counter in a "global" thread-local-storage as I wrote.(also possible to use the same counter/limit in multiple functions!) There were just 2 lines of code to add. Robert -- http://mail.python.org/mailman/listinfo/python-list
