comparison with None

[Steve Holden]

Steven Howe wrote:
> Steven D'Aprano wrote:
>> On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:
>>
>>   
>>>> Which is why I suggested using the explicit type(x) == types.NoneType as 
>>>> opposed to
>>>> x is None
>>>>
>>>>
>>>>       
>>> This seems to go entirely against the spirit of the language. It's about 
>>> as sensible as writing
>>>
>>>    (3 > 4) == True
>>>     
>>
>>
>> Please! For extra certainty, you should write that as:
>>
>> ((int(3) > int(4)) == True) == True
>>
>> Explicit is better than sensible, yes?
>>
>> *wink*
>>
>>
>>
>>   
> Your example, even with the *wink*, is stupid. The language requires 3 
> to be an integer, 4 to be an integer.
> 
It also requires the reader to have a sense of humor. Where did you 
misplace yours? Come on, it was clearly meant to be a light-hearted 
poke, don't take life so seriously.
> 
> The point I was show is with respect to a returned variable (like from a 
> function or method? *wink* *wink*).
> For example, if you expect an open file handle, but get a NoneType 
> because you didn't really open a file (having given a bad name or maybe 
> didn't have permission to open a file), then it would be best to test 
> the type of return object before using it. Then you program could handle 
> the error gracefully (*wink* *wink* *wink*).
> 
Here you are actually arguing for the "is" test without realizing it. 
Since "is" actually checks for object identity ("do my two operands 
occupy the same memory?") it has no need to check the types of its operands.

If there's any possibility that you might have a NoneType (of which, as 
I appear to have to keep reminding you, there is precisely ONE instance, 
so why not just say "None", since it's the ONLY NoneType object in the 
known universe) the correct paradigm is to guard the code with

   if f:
     ...

I am aware that this opens the gates to the hordes who will now pile in 
pointing out that this will technique will fail if f is zero (integer, 
real or complex) or one of the many other items that evaluates to false 
in a Boolean context. I merely point out that none of those things are a 
file, and that to allow f to be *either* a file *or* one of those other 
things is inviting trouble in a very big way.

However, if the hordes *insist* (as the hordes tend to, especially when 
partial to salty snails), the very *most* you need is

   if f is None:
     ...

and anything else is overkill that harms the readability of your 
program. It's that poor readability that Steven D'Aprano was making fun 
of in his remarks above, which in truth only echoes what I felt like but 
refrained from writing when I pointed out the redundancy in the 
expression (3 > 4) == True.

> As much as I love Python, it's ability to morph an object type can be a 
> pain. Testing before using can prevent a program from Error-ing out.
> 
You still don't convince me that there is there is *any* value in 
checking the type of an object to determine whether the object is None. 
If its type is types.NoneType it *must* be None. If it isn't None then 
no harm can be done by an identity comparison with None, since the type 
of the operands is irrelevant to "is".

regards
  Steve

PS: Revision question: How many objects of type NoneType are there?
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Recent Ramblings       http://holdenweb.blogspot.com