On 2006-07-20, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On 20 Jul 2006 08:50:44 GMT, Antoon Pardon <[EMAIL PROTECTED]> > declaimed the following in comp.lang.python: > >> >> Suppose I have the following kind of code: >> >> while True: >> try: >> if len(result) > 0: >> foo() >> else >> bar() >> except TypeError: >> break >> >> This code makes the distinction between the three possibilities, >> whether it is a good way or not I won't discuss, this is just >> meant as an illustration. >> > <shudder> I look at that and my first thought is: > > there is no way to tell if foo() or bar() raised TypeError. > > In the absence of documentation about a tri-state "result" being > normal, my second thought IS that the len(result) > 0 is redundandant; > bar() should be responsible for properly handling the difference between > None and empty conditions. > > A third thought -- foo() and bar() must be implementing hidden > side-effects since the only way out of the loop is by changing result, > and result is not an argument in or out of either foo or bar. > > >> Which isn't at all helpfull with my original problem, but would >> be wrong in the context where the code is actually used. > > Well, in this case, you didn't supply the context (an expected > tri-state return, for example) so most of us would react as to a > two-state model: if result: process data; else: nothing to process > > In your above example, I'd probably even skip the elif format > > while True: > if result is None: break > if result: > foo() > else: > bar() > > It explicitly shows that the value "None" is expected, and is the > signal for loop termination... and that there is different processing > for empty/0 results versus non-empty/non-0 results (and this scheme even > works with scalars, not just sequences)
Thank you for illustrating my point so well. What happened here? You saw some code who made you shudder, and you reacted in a way to get released from that shudder. Whether that reaction would be helpfull or relevant to the problem of the original person seems to be unimportant. What happens a lot is that someone has trouble with some code, a bug or lack of understanding. So he reduces his code to a sample he can use as an illustration of the problem and will easily fit in a news article. That there can be issues with this code is normal, but fixing the code so that these issues go a way, will probably just obscure the point that he is trying to make. So we have code with certain shudder characteristics. And instead of trying to help the OP with his problem, some people react to the shudder and come with all sort of comments that might be true if the code as shown was production code, but which totally miss the point the code was illustrating and thus aren't much helpfull. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list