Re: comparison with None
- From: Steve Holden <steve@xxxxxxxxxxxxx>
- Date: Thu, 19 Apr 2007 13:10:03 -0400
Steven Howe wrote:
Steven D'Aprano wrote: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.On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:Your example, even with the *wink*, is stupid. The language requires 3 to be an integer, 4 to be an integer.
Which is why I suggested using the explicit type(x) == types.NoneType as opposed toThis seems to go entirely against the spirit of the language. It's about as sensible as writing
x is None
(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*
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.
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*).
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
.
- References:
- Re: comparison with None
- From: Alan Isaac
- Re: comparison with None
- From: Steve Holden
- Re: comparison with None
- From: Steven D'Aprano
- Re: comparison with None
- Prev by Date: RE: tkinter canvas
- Next by Date: Re: Python un-plugging the Interpreter
- Previous by thread: Re: comparison with None
- Next by thread: Re: comparison with None
- Index(es):
Relevant Pages
|