Comparison with False - something I don't understand

[Harishankar]

On Sun, 05 Dec 2010 01:59:27 +0000, Steven D'Aprano wrote:

> Of course, this is mainly of theoretical concern. In practice, "Look
> Before You Leap" (test first, then process) is often fine. But there are
> traps to look out for. For example, unless you are running a single-
> process machine, the following code is subject to race conditions and is
> not safe:
> 
> if os.exists(pathname):
>     fp = open(pathname)
> else:
>     handle_missing_file()
> 
> Just because the file is there when os.exists() looks for it, doesn't
> mean it still exists a microsecond later when you try opening it.

I understand this line of thinking. And it makes sense to see why it 
would matter to leave the exception handling mechanism deal with such 
issues.

> 
> Or consider this code:
> 
> if y != 0:
>     result = x/y
> else:
>     handle_division_by_zero()
> 
> 
> This is also unsafe unless you know the type of y. Suppose y is an
> interval quantity that straddles zero, then division by y may fail even
> though y != 0.

Of course in each of these cases the in-built exceptions are used to 
verify the result of certain system level or lower level operations. My 
object was not to deprecate the system-level or other low level 
exceptions thrown by Python, but to consider whether such a mechanism 
would be a preferable method of handling your own programs error-
conditions. 

The issue to be considered by every programmer is to define what can be 
defined as the exceptional condition and what is a condition that merits 
merely different treatment without causing disruption of the normal flow 
of the program.

-- 
Harishankar (http://harishankar.org http://lawstudentscommunity.com)