Coding style

[Antoon Pardon]

On 2006-07-20, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On 20 Jul 2006 08:50:44 GMT, Antoon Pardon <apardon at forel.vub.ac.be>
> 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